[LLVMdev] structs get decomposed when shouldn't

Tim Northover Tim.Northover at arm.com
Wed May 2 02:55:36 PDT 2012


Hi Duncan,

On Wednesday 02 May 2012 10:15:17 Duncan Sands wrote:
> yup, front-ends have to take care of more complicated ABI details.  For
> example the front-end should currently use "byval" for any (parts of)
> structs that need to be passed on the stack, and explicit scalars for
> struct bits that should go in registers.

> > If this interface could be improved, I believe clang simply apply a
> > function to its QualType and produce an LLVM type which does the right
> > thing.
> 
> I don't think this is possible, for example I doubt you can handle the
> x86-64 ABI in a context free way.

Interesting. I've taken a look at http://www.x86-64.org/documentation/abi.pdf.

The complex rule appears to be reversion to stack if not all of an aggregate 
would fit in registers. Couldn't this be implemented rather easily if LLVM 
*did* take note of structs as a whole? Clang would pass pass its aggregate as 
an LLVM struct with each field being an appropriate eightword (or larger if 
SSEUP fields were involved). LLVM would decide whether enough registers are 
free for the whole thing and either use them or shove it on the stack.

Though, having just seen the X86_64 implementation in clang, it's nowhere near 
as horrific as I'd feared it would be. In fact, it's probably significantly 
less code than would be involved in moving it to LLVM, even if it does seem 
wrong for a front-end to care about registers. I think I'll drop this crusade.

> I must have missed that discussion, since I don't know what Ivan's problem
> is.

Essentially that pointers need to go in different registers to integers (and, 
presumably, all other valid MVTs).

Thanks Duncan!

Tim.





More information about the llvm-dev mailing list