[PATCH] D35774: [x86][inline-asm]Extend support for memory reference expression

[Reid Kleckner via Phabricator via llvm-commits]

rnk added a comment.

In https://reviews.llvm.org/D35774#819706, @coby wrote:

> // I would really prefer to see fewer rewrites and more pass through of inline assembly to MC//
>  As do I. What are you suggesting? Keep rewrites to the absolute necessary minimum?
>  Pepole do some funky stuff on MS-Inline-Asm, a large portion of it should be 'legalized' in order for the Assembler to be able to digest.
>  The other way around is to allow this nonsense in the Assembler as well.
>  Both options are bad, but I believe the latter is a bit more.
>
> If it's of any comfort - have this 'new' rewrite is to be allowed - AOK_Imm/AOK_ImmPrefix/AOK_SizeDirective can be implemented as a special case of it (AOK_DotOperator should be cancelled).
>  Net effect will remain the same - but it'll be (possibly) less of a mess of code.


Hm, rewriting everything in terms of a general AOK_IntelExpr does sound better, even if it is kind of the opposite direction from what I was thinking. :) What I'm imagining is that any time there is a symbolic reference to C/C++ enums, globals, or variables, we basically fully parse that operand and decompose it into the usual parts of an X86 memory operand: segment, base, index, scale, displacement, etc, check that those parts make sense, and emit a completely rewritten operand. Right now the parsing code in MC has a hard time deciding what's legal because it doesn't know whether certain C/C++ variable references refer to stack locals or global variables. A local variable will require using a base register, but a global will not, but on x86_64, a global will require %rip-relative addressing, which can't use base+index registers.

Doing this exposes a lot of x86 details that aren't really supposed to be in the supposedly target neutral asmparser interface. That battle may already be lost, though.


Repository:
  rL LLVM

https://reviews.llvm.org/D35774