-The front-end now builds a single assembly string and feeds it to the
AsmParser. The front-end iterates on a per statement basis by calling the
ParseStatement() function. Please note, the calling of ParseStatement() and
and any notion of MCAsmParsedOperands will be sunk into the MC layer in the
near future. I plan to expose more basic APIs such as getClobbers, etc.
-The enumeration of the AsmString expressions have been reworked to use SMLocs
rather than assembly Pieces, which were being parsed in the front-end.
-The test case, t8(), was modified due to r129223. I'll have to find a way to
work around things such as these.
Sorry for the large commit, but breaking this in multiple smaller commits proved
too irritating.
llvm-svn: 165957
now unused static helper function.
The test case needs to be remove temporarily until I can better filter memory
operands that aren't actual variable reference.
llvm-svn: 165751
more robust way to address a few FIXMEs.
The initial implementation, r163342, built the IR asm string and then tried to
patch things on the fly without enough context. Specifically, it didn't skip
mnemonics nor did it track with assembly instruction an expression was related
to. The new implementation patches the operands and then builds the final
IR string.
llvm-svn: 163756
MCOperands then iterate over all of then when computing clobbers, inputs and
outputs.
On x86 the 1-to-many mapping is a memory operand that includes a BaseReg(reg),
MemScale(imm), MemIndexReg(reg), an Expr(MCExpr or imm) and a MemSegReg(reg).
Invalid register (Op.getReg() == 0) are not considered when computing clobber.
llvm-svn: 163728
These require special handling, which we don't currently handle. This is being
put in place to ensure we don't do invalid symbol table lookups or try to parse
invalid assembly. The test cases just makes sure the latter isn't happening.
llvm-svn: 162050
variables, function or label references. The former is a potential clobber.
The latter is either an input or an output. Unfortunately, it's difficult to
test this patch at the moment, but the added test case will eventually do so.
llvm-svn: 162026
statement. For example,
if (x)
__asm out dx, ax __asm out dx, ax
results in a single inline asm statement (i.e., both "out dx, ax" statements are
predicated on if(x)).
llvm-svn: 161986
The AsmParser expects a single asm instruction, but valid ms-style inline asm
statements may contain multiple instructions.
This happens with asm blocks
__asm {
mov ebx, eax
mov ecx, ebx
}
or when multiple asm statements are adjacent to one another
__asm mov ebx, eax
__asm mov ecx, ebx
and
__asm mov ebx, eax __asm mov ecx, ebx
Currently, asm blocks are not properly handled.
llvm-svn: 161780
Chad Rosier