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

[coby via Phabricator via llvm-commits]

coby marked 2 inline comments as done.
coby added a comment.

In https://reviews.llvm.org/D35774#822227, @rnk wrote:

> 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.**


This battle can fairly been viewed as lost, until a 'global' refactoring/reconsideration will be announced (if ever) regarding the way targets' specific parsers and AsmParser are to integrate one with each other, in terms of responsibilities. those 'leaks' you've mentioned from X86 to AsmParser are a fine exhibition of it. I have some ideas regarding how we may overcome/'hide' such phenomena in a way which should make rewrites unnecessary, but they are currently seem 'too heavy' (and reaching code parts wihch I should get more familiar with ere tempering). perhaps a llvm-dev discussion should be commenced? to either find a more clean and elegant way, or setting 'guidelines' which will confine this witchcraft to an agreed upon, tolerable minimum.
**In the meantime - I deem we should 'allow' ourselves to 'rewrite' only where no scale-able alternative can be convinced, and try to concentrate/uniform all rewrites under one hood (in an utopic future - it should ease rewrites elimination)**


Repository:
  rL LLVM

https://reviews.llvm.org/D35774