Allow extended parsing of variable assembler assignment syntax and modify X86 to permit
VAR = register assignment. As we emit these as .set directives when possible, we inline
such expressions in output assembly.
Fixes PR37425.
Differential D47545
[MC][X86] Allow assembler variable assignment to register name. niravd on May 30 2018, 11:08 AM. Authored by
Details Allow extended parsing of variable assembler assignment syntax and modify X86 to permit Fixes PR37425.
Diff Detail
Event TimelineComment Actions This breaks the invariant that an MCSymbol is always a relocatable symbol. I wonder if the better way to do this would be to pretend what we actually saw was a macro definition when the RHS of an assignment doesn't parse as an MCExpr, which is basically a language for relocatable expressions. I'm not familiar enough with gas syntax to know what the equivalent directives would be. I see the #define suggestion in the bug, but is there a gas-only way to express that? We seem to support macros with arguments, but is there a way to express argument-less macros? Comment Actions That's part of why these symbols are inlined and assignments are elided in the assembly output. I agree it'd better to other variable layers, but neither the C++ processor or assembler macro work. For the former case because of order of evaluation compared to assembler functions; for the latter because assembler macro handling assumes instantiated macros are complete assembly statements.
Comment Actions Since we've only found 2 cases needing this extension and none requiring us to accept a larger set of expressions, I think we should defer any more work until we find such a case in the wild. Reid, can I get an LGTM?
Comment Actions lgtm
|
Given that we already have logic like this, I'm OK with this. I guess gnu as treats = assignments much more textually than we do.