[LLVMdev] Extended Inline asm with double data type crashes clang

Jakob Stoklund Olesen stoklund at 2pi.dk
Mon Nov 26 10:11:06 PST 2012


On Nov 26, 2012, at 9:43 AM, Eric Christopher <echristo at gmail.com> wrote:
> 
> Of course, while writing this, I just realized this is a variant of a
> bug which has been discussed on llvm-commits: PR13622.  And gcc
> actually does implement pairs on x86; I think the choice of registers
> is based on some internal register allocator sequence.  And gcc also
> knows how to allocate register triplets on x86 (though I have no clue
> how you would use them). :)
> 
> Ugh, I wish gcc's inline asm extension didn't expose so much of the
> insanity of gcc internals.
> 
> Yes, inline assembly that exposes register allocation details is pretty annoying.
> 
> Jakob: Thoughts on how you'd want to model this as it goes through the allocator?

The allocator wants all constraints expressed as register classes. Even-odd pairs of consecutive registers should be modeled as pseudo-registers. This is what Weiming is currently working on for ARM register pairs using the new GPRPair register class. (Feel free to review his patch from 11/19).

However, a pair of registers that don't constrain the register allocator should be modeled as two separate virtual registers.

So if GCC is using register pairs just to model an illegal type like i64 on ARM, the constraint should be handled by multiple virtual registers. If there are additional constraints on the register pair (e.g. they must be consecutive), the pair should be modeled as a single virtual register with sub-registers.

The INLINEASM MachineInstr already supports a single constraint mapping to multiple MachineOperands. X86 "m" constraints map to 5 operands, for example. A single "r" constraint should be able to map to multiple register operands as well.

/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121126/8af364d7/attachment.html>


More information about the llvm-dev mailing list