[PATCH] D73227: [ms] [llvm-ml] Use default RIP-relative addressing for x64 MASM.

Eric Astor via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 22 08:06:20 PDT 2020


epastor marked an inline comment as done.
epastor added inline comments.


================
Comment at: llvm/lib/Target/X86/AsmParser/X86Operand.h:63
     unsigned BaseReg;
+    unsigned DefaultBaseReg;
     unsigned IndexReg;
----------------
epastor wrote:
> thakis wrote:
> > epastor wrote:
> > > rnk wrote:
> > > > I'd really like to get by without adding more operand members that don't correspond to parts of the x86 addressing mode.
> > > Agreed. Unfortunately, the only obvious way to do that would be to match the x64 addressing mode more closely, and assume that all non-absolute memory references lacking a BaseReg are RIP-relative... which would break GNU-style assembly, since they made the decision to enforce explicit RIP-relative referencing.
> > It sounds like ms-style 64-bit assembly with a msvc triple will already be incompatible with gnu-style assembly, due to the rip-relative differences. Is that incorrect?
> > 
> > If not, I think we should have the GNU mode and the msvc mode here, and not a third kinda-hybrid mode. It sounds like this is currently some hybrid mode.
> > 
> > If needed, we could have the full commandline flag / pragma dance for picking a mode for inline asm and only setting the default mode off the triple if use cases for that emerge, but that can happen later.
> > 
> > (Maybe I misunderstood what you're saying, though.)
> What I'm saying is that we can't know whether or not to assume RIP-relative (in MSVC mode) until AFTER the Operand has been matched to an instruction, as only MASM instructions that allow relative addressing will default to RIP-relative if no other base register is specified. However, once the Operand is matched, we lose information on whether it's come from MASM or GNU-style assembly. (We do allow GNU-style assembly for MSVC platforms already.) This means that when we're finally about to emit our instruction and need the base register, we don't know whether to translate a NoReg base as actually implying RIP.
> 
> To handle that, I opted to extend the Operand here with a DefaultBaseReg, which we use as our Base if no base register has been specified. When we parse GNU-style assembly, this defaults to NoReg... when we parse MASM-style assembly, it gets set to RIP.
One more try at clarifying this: MS-style assembly with an MSVC triple and GNU-style assembly with an MSVC triple both work now, and will both work in the future. The only difference is that MS-style assembly instructions that allow relative addressing will use a default RIP-relative address, while GNU-style assembly forces the user to always be explicit about RIP-relative addressing.

Since only relative-addressing contexts in MS-style assembly use the implicit RIP-relative convention, we can't just pick a mode and stick with it. Instead, we label our Operands with how their source assembly wants them treated if used in relative-addressing context without a base register. After we've matched in relative-addressing context, if the base register is not present, we implement the approach given by the source assembly.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73227/new/

https://reviews.llvm.org/D73227





More information about the llvm-commits mailing list