[LLVMdev] Inline Assembly: Memory constraints with offsets

Ulrich Weigand Ulrich.Weigand at de.ibm.com
Mon Mar 9 07:30:26 PDT 2015

Daniel Sanders <Daniel.Sanders at imgtec.com> wrote on 09.03.2015 11:22:02:

> I've had some luck with this. It turns out that the ISD::INLINE_ASM
> node has a flag operand corresponding to each operand in the source
> code. It's used for storing things like the matched operand number
> for the [0-9]+ constraints,  the register class id for register
> constraints, etc. At first glance, the encoding looks full but it
> appears that when the lowest 3 bits are Kind_Mem (meaning it's a
> memory constraint), the upper 16-bits are never used. I've therefore
> used this gap to store a constraint ID which can then be inspected
> during instruction selection. The mapping from constraint string to
> constraint id is provided by a target specific hook with unmapped
> constraints causing a failure (currently an assertion but it should
> be llvm_unreachable). I now have the Mips 'ZC' constraint supporting
> 12-bit offsets while 'm' continues to lack support for offsets. This
> isn't the correct behaviour for 'ZC' or for 'm' but it does at least
> demonstrate that different memory constraints can now behave
> differently. My WIP patch is at http://reviews.llvm.org/D8160. It's
> going to be split up into multiple patches and the Mips portion is
> going to be corrected before I upstream it. I'll also check the
> clang tests to see if I've missed any supported constraints.
> There's a few odd target specific things in the current code so I've
> CC'd the code owners. I couldn't find a code owner for PowerPC or
> MSP430 in CODE_OWNERS.txt though.

The code owner for PowerPC is Hal Finkel (added on CC).

> The Hexagon and X86 backends both had code that attempted to
> implement different behaviour for the 'o' and 'v' memory constraints
> but this code has been unused so far because the backend always
> received the code 'm'. I attempted to use the existing
> implementations for these but this causes test failures so I've left
> them behaving like 'm'.
> The AArch64, ARM, PowerPC, and SystemZ backends have tests for a few
> constraints that currently behave like 'm'. I assume that keeping
> the 'm' behaviour is ok for now.

Sure.  Once the infrastructure is in, I'll update SystemZ to make use
of the additional constraints.   Thanks for taking care of this!


More information about the llvm-dev mailing list