shift-by-1 instructions, where the asmstring doesn't contain
the implicit 1. It turns out that a bunch of these rotate
instructions were completely broken because they used 1
instead of $1.
This fixes assembly mismatches on "rclb $1, %bl" and friends,
where we used to generate the 3 byte form, we now generate the
proper 2-byte form.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118355 91177308-0d34-0410-b5e6-96231b3b80d8
fixed physical registers. Start moving fp comparison
aliases to the .td file (which default to using %st1 if
nothing is specified).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118352 91177308-0d34-0410-b5e6-96231b3b80d8
(surprise!) a list of registers. Register lists are consecutive, so we only need
to record the start register plus the number of registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118351 91177308-0d34-0410-b5e6-96231b3b80d8
floating point stack instructions instead of looking for b/w/l/q.
This fixes issues where we'd accidentally match fistp to fistpl,
when it is in fact an ambiguous instruction.
This changes the behavior of llvm-mc to reject fstp, which was the
correct fix for rdar://8456389:
t.s:1:1: error: ambiguous instructions require an explicit suffix (could be 'fstps', 'fstpl', or 'fstpt')
fstp (%rax)
it also causes us to correctly reject fistp and fist, which addresses
PR8528:
t.s:2:1: error: ambiguous instructions require an explicit suffix (could be 'fistps', or 'fistpl')
fistp (%rax)
^
t.s:3:1: error: ambiguous instructions require an explicit suffix (could be 'fists', or 'fistl')
fist (%rax)
^
Thanks to Ismail Donmez for tracking down the issue here!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118346 91177308-0d34-0410-b5e6-96231b3b80d8
result instruction operand numbering matched the result pattern.
Fixing this allows us to move the xchg/test aliases to the .td file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118334 91177308-0d34-0410-b5e6-96231b3b80d8
operand list instead of the operand list redundantly declared on the alias
or instruction.
With this change, we finally remove the ins/outs list on the alias. Before:
def : InstAlias<(outs GR16:$dst), (ins GR8 :$src),
"movsx $src, $dst",
(MOVSX16rr8W GR16:$dst, GR8:$src)>;
After:
def : InstAlias<"movsx $src, $dst",
(MOVSX16rr8W GR16:$dst, GR8:$src)>;
This also makes the alias mechanism more general and powerful, which will
be exploited in subsequent patches.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118329 91177308-0d34-0410-b5e6-96231b3b80d8
(someinst GR16:$foo, GR32:$foo)
Reimplement BuildAliasOperandReference to be correctly
based on the names of operands in the result pattern,
instead of on the instruction operand definitions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118328 91177308-0d34-0410-b5e6-96231b3b80d8
to perform the copy, which may be of lots of memory [*]. It would be good if the
fall-back code generated something reasonable, i.e. did the copy in a loop, rather
than vast numbers of loads and stores. Add a note about this. Currently target
specific code seems to always kick in so this is more of a theoretical issue rather
than a practical one now that X86 has been fixed.
[*] It's amazing how often people pass mega-byte long arrays by copy...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118275 91177308-0d34-0410-b5e6-96231b3b80d8
sequence of loads and stores was being generated to perform the
copy on the x86 targets if the parameter was less than 4 byte
aligned, causing llc to use up vast amounts of memory and time.
Use a "rep movs" form instead. PR7170.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118260 91177308-0d34-0410-b5e6-96231b3b80d8
