[LLVMdev] Inline Assembly: Memory constraints with offsets

Daniel Sanders Daniel.Sanders at imgtec.com
Wed Mar 4 08:42:22 PST 2015


> -----Original Message-----
> From: Daniel Sanders
> Sent: 03 March 2015 16:23
> To: 'Tim Northover'
> Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
> Subject: RE: [LLVMdev] Inline Assembly: Memory constraints with offsets
> 
> > -----Original Message-----
> > From: Tim Northover [mailto:t.p.northover at gmail.com]
> > Sent: 03 March 2015 14:42
> > To: Daniel Sanders
> > Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
> > Subject: Re: [LLVMdev] Inline Assembly: Memory constraints with offsets
> >
> > > Does anyone have any suggestions as to how I can get the offset inside
> the
> > > inline assembly?
> >
> > I think x86 has the same capability with a simple "m" constraint.
> > Looks like it's based on the "SelectInlineAsmMemoryOperand" function.
> >
> > Cheers.
> >
> > Tim.
> 
> Thanks. I came across SelectInlineAsmMemoryOperand but the caller I found
> is passing a hardcoded 'm' into it. I'll start by seeing if the 'o' and 'v' paths
> really trigger for X86.

It turns out that those paths don't trigger. I've made a small change to print the ConstraintCode when this function is called and found that the following code:
  int data[10];
  void o(void) {
    asm volatile ("foo %0" : : "o"(data[1]));
  }
  // The 'v' case is commented out because clang doesn't actually accept it in the frontend despite having a backend implementation.
  //void v(void) {
  //  asm volatile ("foo %0" : : "v"(data[1]));
  //}
  void m(void) {
    asm volatile ("foo %0" : : "m"(data[1]));
  }
when compiled for X86, only prints 'm' during compilation and never 'o'. It appears that only 'm' and equivalent constraints can be implemented.

I think the 'm' is hardcoded because the constraints aren't present in the SelectionDAG nodes and I think they're not present because it's difficult to represent them. I expect the 'm' was good enough at the time and Mips might be the first target to need sufficiently complicated constraints for it to be a problem. I'll have to have a think as to how I can deliver the constraint code to this function nicely.




More information about the llvm-dev mailing list