This new API will be used by clang to parse ms-style inline asms.
One goal of this project is to use this style of inline asm for targets other
then x86. Therefore, this API needs to be implemented for non-x86 targets at
some point in the future.
llvm-svn: 161624
rdar://10873652
As part of this I updated the llvm-mc disassembler C API to always call the
SymbolLookUp call back even if there is no getOpInfo call back. If there is a
getOpInfo call back that is tried first and then if that gets no information
then the SymbolLookUp is called. I also made the code more robust by
memset(3)'ing to zero the LLVMOpInfo1 struct before then setting
SymbolicOp.Value before for the call to getOpInfo. And also don't use any
values from the LLVMOpInfo1 struct if getOpInfo returns 0. And also don't
use any of the ReferenceType or ReferenceName values from SymbolLookUp if it
returns NULL. rdar://10873563 and rdar://10873683
For the X86 target also fixed bugs so the annotations get printed.
Also fixed a few places in the ARM target that was not producing symbolic
operands for some instructions. rdar://10878166
llvm-svn: 151267
In att style asm syntax memory operand size is derived from suffix attached with mnemonic. In intel style asm syntax it is part of memory operand hence predicate method check is required to select appropriate instruction.
llvm-svn: 148006
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.
llvm-svn: 142106
Allow a target assembly parser to do context sensitive constraint checking
on a potential instruction match. This will be used, for example, to handle
Thumb2 IT block parsing.
llvm-svn: 137675
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
llvm-svn: 136292
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.
llvm-svn: 136287
Update the debug output interface for MCParsedAsmOperand to have a print()
method which takes an output stream argument, an << operator which invokes
the print method using the given stream, and a dump() method which prints
the operand to the dbgs() stream. This makes the interface more consistent
with the rest of LLVM, and more convenient to use at the debugger command
line.
llvm-svn: 135043
and MCSubtargetInfo.
- Added methods to update subtarget features (used when targets automatically
detect subtarget features or switch modes).
- Teach X86Subtarget to update MCSubtargetInfo features bits since the
MCSubtargetInfo layer can be shared with other modules.
- These fixes .code 16 / .code 32 support since mode switch is updated in
MCSubtargetInfo so MC code emitter can do the right thing.
llvm-svn: 134884
CPU, and feature string. Parsing some asm directives can change
subtarget state (e.g. .code 16) and it must be reflected in other
modules (e.g. MCCodeEmitter). That is, the MCSubtargetInfo instance
must be shared.
llvm-svn: 134795
- Each target asm parser now creates its own MCSubtatgetInfo (if needed).
- Changed AssemblerPredicate to take subtarget features which tablegen uses
to generate asm matcher subtarget feature queries. e.g.
"ModeThumb,FeatureThumb2" is translated to
"(Bits & ModeThumb) != 0 && (Bits & FeatureThumb2) != 0".
llvm-svn: 134678
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.
llvm-svn: 120260
sahf movl 344(%rdi),%r14d
we used to produce:
t.s:2:1: error: unexpected token in argument list
^
we now produce:
t.s:1:11: error: unexpected token in argument list
sahf movl 344(%rdi),%r14d
^
rdar://8581401
llvm-svn: 119676
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.
llvm-svn: 118355
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!
llvm-svn: 118346
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.
llvm-svn: 117901
directives, allowing things like this:
def : MnemonicAlias<"pop", "popl">, Requires<[In32BitMode]>;
def : MnemonicAlias<"pop", "popq">, Requires<[In64BitMode]>;
Move the rest of the X86 MnemonicAliases over to the .td file.
llvm-svn: 117830
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.
llvm-svn: 117433
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).
llvm-svn: 117031
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 .
llvm-svn: 116773
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
My previous fix for rdar://8456371 should only apply to fmulp/faddp,
not to fmul/fadd. Instruction set orthogonality is overrated or
something.
llvm-svn: 114818
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
the end of the line on a parser error, allowing skipping to happen
for syntactic errors but not for semantic errors. Before we would
miss emitting a diagnostic about the second line, because we skipped
it due to the semantic error on the first line:
foo %eax
bar %al
This fixes rdar://8414033 - llvm-mc ignores lines after an invalid instruction mnemonic errors
llvm-svn: 113688
always be disambiguated as sldtw. sldtw and sldtq with
a mem operands have the same effect, but sldtw is more
compact. Force it to sldtw, resolving rdar://8017530
llvm-svn: 113186
of a mneumonic, report operand errors with better location
info. For example, we now report:
t.s:6:14: error: invalid operand for instruction
cwtl $1
^
but we fail for common cases like:
t.s:11:4: error: invalid operand for instruction
addl $1, $1
^
because we don't know if this is supposed to be the reg/imm or imm/reg
form.
llvm-svn: 113178
failed because a subtarget feature was not enabled. Use this to
remove a bunch of hacks from the X86AsmParser for rejecting things
like popfl in 64-bit mode. Previously these hacks weren't needed,
but were important to get a message better than "invalid instruction"
when used in the wrong mode.
This also fixes bugs where pushal would not be rejected correctly in
32-bit mode (just pusha).
llvm-svn: 113166
- Currently includes a hack to limit ourselves to "In32BitMode" and "In64BitMode", because we don't have the other infrastructure to properly deal with setting SSE, etc. features on X86.
llvm-svn: 108677
- Unfortunate, but necessary for now to handle subtarget instruction matching. Eventually we should factor out the lower level target machine information so we don't need to do this.
llvm-svn: 108664
instruction. Added the 64-bit version "jrcxz" so it is recognized and also
added the checks for incorrect uses of "jcxz" in 64-bit mode and "jrcxz" in
32-bit mode. Still to do is to correctly handle the encoding of the
instruction adding the Address-size override prefix byte, 0x67, when the width
of the count register is not the same as the mode the machine is running in.
Which for example means the encoding of "jecxz" depends if you are assembling
as a 32-bit target or a 64-bit target.
llvm-svn: 105661
are st(0). These can be encoded using an opcode for storing in st(0) or using
an opcode for storing in st(i), where i can also be 0. To allow testing with
the darwin assembler and get a matching binary the opcode for storing in st(0)
is now used. To do this the same logical trick is use from the darwin assembler
in converting things like this:
fmul %st(0), %st
into this:
fmul %st(0)
by looking for the second operand being X86::ST0 for specific floating point
mnemonics then removing the second X86::ST0 operand. This also has the add
benefit to allow things like:
fmul %st(1), %st
that llvm-mc did not assemble.
llvm-svn: 104634
instructions which have no direct register usage.
Darwin 'as' accepts:
add $0, (%rax)
but rejects
mov $0, (%rax)
for example.
Given that, only accept suffix matches which match exactly one form. We still
need to emit nice diagnostics for failures...
llvm-svn: 103015
- The idea is that when a match fails, we just try to match each of +'b', +'w',
+'l'. If exactly one matches, we assume this is a mnemonic prefix and accept
it. If all match, we assume it is width generic, and take the 'l' form.
- This would be a horrible hack, if it weren't so simple. Therefore it is an
elegant solution! Chris gets the credit for this particular elegant
solution. :)
- Next step to making this more robust is to have the X86 matcher generate the
mnemonic prefix information. Ideally we would also compute up-front exactly
which mnemonic to attempt to match, but this may require more custom code in
the matcher than is really worth it.
llvm-svn: 103012
temporary workaround for matching inc/dec on x86_64 to the correct instruction.
- This hack will eventually be replaced with a robust mechanism for handling
matching instructions based on the available target features.
llvm-svn: 98858
Chad Rosier