| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 117822
|
|
|
|
| |
llvm-svn: 117821
|
|
|
|
| |
llvm-svn: 117819
|
|
|
|
| |
llvm-svn: 117818
|
|
|
|
| |
llvm-svn: 117817
|
|
|
|
|
|
|
| |
just remaps one mnemonic to another. Convert a few of the X86 aliases
from .cpp to .td code.
llvm-svn: 117815
|
|
|
|
| |
llvm-svn: 116984
|
|
|
|
| |
llvm-svn: 116972
|
|
|
|
|
|
|
|
|
|
| |
be more complete. These are only expected to be used by llvm-mc with assembly
source so there is no pattern, [], in the .td files. Most are being added to
X86InstrInfo.td as Chris suggested and only comments about register uses are
added. Suggestions welcome on the .td changes as I'm not sure on every detail
of the x86 records. More missing instructions will be coming.
llvm-svn: 116716
|
|
|
|
|
|
| |
8 bit constants can be used.
llvm-svn: 116403
|
|
|
|
| |
llvm-svn: 116319
|
|
|
|
|
|
|
|
|
|
|
| |
The reg-reg copies were no longer being generated since copyPhysReg copies
physical registers only.
The loads and stores are not necessary - The TC constraint is imposed by the
TAILJMP and TCRETURN instructions, there should be no need for constrained loads
and stores.
llvm-svn: 116314
|
|
|
|
|
|
|
|
| |
"Reimplement (part of) the or -> add optimization. Matching 'or' into 'add'"
With a critical fix: the add pseudos clobber EFLAGS.
llvm-svn: 116039
|
|
|
|
|
|
| |
'add'", which seems to have broken just about everything.
llvm-svn: 116033
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is general goodness because it allows ORs to be converted to LEA to avoid
inserting copies. However, this is bad because it makes the generated .s
file less obvious and gives valgrind heartburn (tons of false positives in
bitfield code).
While the general fix should be in valgrind, we can at least try to avoid
emitting ADD instructions that *don't* get promoted to LEA. This is more
work because it requires introducing pseudo instructions to represents
"add that knows the bits are disjoint", but hey, people really love valgrind.
This fixes this testcase:
https://bugs.kde.org/show_bug.cgi?id=242137#c20
the add r/i cases are coming next.
llvm-svn: 116007
|
|
|
|
|
|
| |
not getting marked as mayStore. This fixes llvm-gcc bootstrap.
llvm-svn: 115693
|
|
|
|
|
|
| |
gross hack (having the asmmatcher handle the alias).
llvm-svn: 115685
|
|
|
|
|
|
| |
the right places. X86Instr64bit.td now dies, long live x86-64!
llvm-svn: 115669
|
|
|
|
| |
llvm-svn: 115627
|
|
|
|
| |
llvm-svn: 115607
|
|
|
|
| |
llvm-svn: 115605
|
|
|
|
|
|
| |
bswap32 doesn't read eflags.
llvm-svn: 115604
|
|
|
|
|
|
|
|
| |
pseudo instructions.
Move POPCNT to InstrSSE since they are SSE4 instructions.
llvm-svn: 115603
|
|
|
|
|
|
| |
with the 32-bit stuff.
llvm-svn: 115602
|
|
|
|
| |
llvm-svn: 115601
|
|
|
|
|
|
| |
32-bit together.
llvm-svn: 115600
|
|
|
|
| |
llvm-svn: 115599
|
|
|
|
| |
llvm-svn: 115598
|
|
|
|
| |
llvm-svn: 115597
|
|
|
|
|
|
|
|
| |
control flow stuff out to X86InstrControl.td. Move
some compiler pseudo instructions and Pat<> patterns
out to X86InstrCompiler.td
llvm-svn: 115596
|
|
|
|
| |
llvm-svn: 115591
|
|
|
|
|
|
|
|
|
|
|
| |
else in X86), and add support for pavgusb. This is apparently the
only instruction (other than movsx) that is preventing ffmpeg from building
with clang.
If someone else is interested in banging out the rest of the 3DNow!
instructions, it should be quite easy now.
llvm-svn: 115466
|
|
|
|
| |
llvm-svn: 115429
|
|
|
|
|
|
|
|
| |
instructions. After further
reflection, this isn't going to achieve the purpose I intended it for. Back to the drawing board!
llvm-svn: 114710
|
|
|
|
| |
llvm-svn: 114703
|
|
|
|
|
|
|
|
|
|
|
|
| |
x86-32: 32-bit calls were named "call" not "calll". 64-bit calls were correctly
named "callq", so this only impacted x86-32.
This fixes rdar://8456370 - llvm-mc rejects 'calll'
This also exposes that mingw/64 is generating a 32-bit call instead of a 64-bit call,
I will file a bugzilla.
llvm-svn: 114534
|
|
|
|
|
|
| |
SegmentBaseAddress.
llvm-svn: 114529
|
|
|
|
| |
llvm-svn: 114515
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by having X86DAGToDAGISel::SelectAddr get passed in the parent node
of the operand match (the load/store/atomic op) and having it get
the address space from that, instead of having special FS/GS addr
mode operations that require duplicating the entire instruction set
to support.
This makes FS and GS relative accesses *far* more predictable and
work much better. It also simplifies the X86 backend a bit, more
to come.
There is still a pending issue with nodes like ISD::PREFETCH and
X86ISD::FLD, which really should be MemSDNode's but aren't.
llvm-svn: 114491
|
|
|
|
| |
llvm-svn: 114468
|
|
|
|
|
|
| |
What a weird instruction.
llvm-svn: 114190
|
|
|
|
|
|
|
| |
add sldt GR32, which isn't documented in the intel manual
but which gas accepts. Part of rdar://8418316
llvm-svn: 113938
|
|
|
|
| |
llvm-svn: 113422
|
|
|
|
| |
llvm-svn: 113350
|
|
|
|
|
|
| |
fixing rdar://8403974
llvm-svn: 113349
|
|
|
|
|
|
| |
rdar://8061602
llvm-svn: 113343
|
|
|
|
| |
llvm-svn: 113259
|
|
|
|
|
|
| |
allowing unsigned 8-bit operands. This fixes rdar://8208481
llvm-svn: 113182
|
|
|
|
| |
llvm-svn: 113158
|
|
|
|
| |
llvm-svn: 112921
|