not depend on In32BitMode. Use the sysexitq mnemonic for the version with the
REX.W prefix and only allow it only In64BitMode. rdar://9738584
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143112 91177308-0d34-0410-b5e6-96231b3b80d8
the X86 asmparser to produce ranges in the one case that was annoying me, for example:
test.s:10:15: error: invalid operand for instruction
movl 0(%rax), 0(%edx)
^~~~~~~
It should be straight-forward to enhance filecheck, tblgen, and/or the .ll parser to use
ranges where appropriate if someone is interested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142106 91177308-0d34-0410-b5e6-96231b3b80d8
for cpp pre-processed assembly we give correct filename and line numbers when
reporting errors in assembly files when using clang and -integrated-as on .s
files. rdar://8998895
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141814 91177308-0d34-0410-b5e6-96231b3b80d8
This can happen in cases where TableGen generated asm matcher cannot check
whether a register operand is in the right register class. e.g. mem operands.
rdar://8204588
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136292 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-mc gives an "invalid operand" error for instructions that take an unsigned
immediate which have the high bit set such as:
pblendw $0xc5, %xmm2, %xmm1
llvm-mc treats all x86 immediates as signed values and range checks them.
A small number of x86 instructions use the imm8 field as a set of bits.
This change only changes those instructions and where the high bit is not
ignored. The others remain unchanged.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136287 91177308-0d34-0410-b5e6-96231b3b80d8
to emit "movd" across the board to continue supporting a Darwin assembler bug.
This is the reincarnation of r133452.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133565 91177308-0d34-0410-b5e6-96231b3b80d8
These are just FXSAVE and FXRSTOR with REX.W prefixes. These versions use
64-bit pointer values instead of 32-bit pointer values in the memory map they
dump and restore.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125446 91177308-0d34-0410-b5e6-96231b3b80d8
instructions. I choose to handle this with an asmparser hack,
though it could be handled by changing all the instruction definitions
to allow be "setneb" instead of "setne". The asm parser hack is
better in this case, because we want the disassembler to produce
setne, not setneb.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120260 91177308-0d34-0410-b5e6-96231b3b80d8
different forms of this instruction (movw/movl/movq) which we reported
as being ambiguous. Since they all do the same thing, gas just picks the
one with the shortest encoding. Follow its lead here.
This implements rdar://8208615
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118362 91177308-0d34-0410-b5e6-96231b3b80d8
exposed:
GAS doesn't accept "fcomip %st(1)", it requires "fcomip %st(1), %st(0)"
even though st(0) is implicit in all other fp stack instructions.
Fortunately, there is an alias for fcomip named "fcompi" and gas does
accept the default argument for the alias (boggle!).
As such, switch the canonical form of this instruction to "pi" instead
of "ip". This makes the code generator and disassembler generate pi,
avoiding the gas bug.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118356 91177308-0d34-0410-b5e6-96231b3b80d8
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
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
aliases installed and working. They now work when the
matched pattern and the result instruction have exactly
the same operand list.
This is now enough for us to define proper aliases for
movzx and movsx, implementing rdar://8017633 and PR7459.
Note that we do not accept instructions like:
movzx 0(%rsp), %rsi
GAS accepts this instruction, but it doesn't make any
sense because we don't know the size of the memory
operand. It could be 8/16/32 bits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117901 91177308-0d34-0410-b5e6-96231b3b80d8
in their asmstring. Fix the two x86 "NOREX" instructions that have them.
If these comments are important, the instlowering stuff can print them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117897 91177308-0d34-0410-b5e6-96231b3b80d8
sense, when the instruction takes the 16-bit ax register or m16 memory
location. These changes to llvm-mc matches what the darwin assembler
allows for these instructions. Done differently than in r117031 that
caused a valgrind error which was later reverted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117433 91177308-0d34-0410-b5e6-96231b3b80d8
will accept versions that the darwin assembler allows. Forms ending in "pi" and
forms without all the operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117427 91177308-0d34-0410-b5e6-96231b3b80d8
It doesn't look like anything is wrong with the checkin,
but the new test cases expose a mem bug in AsmParser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117087 91177308-0d34-0410-b5e6-96231b3b80d8
sense, when the instruction takes the 16-bit ax register or m16 memory
location. These changes to llvm-mc matches what the darwin assembler allows
for these instructions. Also added the missing flex (without the wait prefix)
and ud2a as an alias to ud2 (still to add ud2b).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117031 91177308-0d34-0410-b5e6-96231b3b80d8
word forms and suffixed versions to match the darwin assembler in 32-bit and
64-bit modes. This is again for use just with assembly source for llvm-mc .
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116773 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116716 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115466 91177308-0d34-0410-b5e6-96231b3b80d8
