[LLVMdev] Inline Assembly: Memory constraints with offsets

[Hal Finkel]

----- Original Message -----
> From: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>
> To: "Daniel Sanders" <Daniel.Sanders at imgtec.com>
> Cc: adasgupt at codeaurora.org, "evan cheng" <evan.cheng at apple.com>, "Krzysztof Parzyszek" <kparzysz at codeaurora.org>,
> llvmdev at cs.uiuc.edu, nrotem at apple.com, "t p northover" <t.p.northover at gmail.com>, "Hal Finkel" <hfinkel at anl.gov>
> Sent: Monday, March 9, 2015 9:30:26 AM
> Subject: RE: [LLVMdev] Inline Assembly: Memory constraints with offsets
> 
> 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).

I'd like to second Uli's comment: Thanks for working on this! This is a code quality issue that affects PowerPC too.

 -Hal

> 
> > 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!
> 
> 
> Bye,
> Ulrich
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory