[LLVMdev] [llvm-commits] [cfe-commits] [Patch?] Fix handling of ARM homogenous aggregates

[Tim Northover]

> I think that ABI of LLVM IR level is different from ABI on real architecture
> such as ARM or x86. ABI of LLVM IR level doesn't consider about register
> usage. It just describes parameters and padding information related to
> alignment of parameters. 

I'm not sure what you mean here. LLVM's IR certainly doesn't care about 
registers and so on, but the LLVM backends have to, and front-ends have to 
know to a greater or lesser degree how the backends actually do it so that 
they can create ABI compliant code.

My view (possibly biased by the ARM ABI) is that LLVM's primary goal should be 
to make writing an ABI-compliant front-end as easy as possible. After that it 
should aim to have a sane ABI for hand-written LLVM code, and finally it 
should try to follow the ABI itself where possible (the last two are possibly 
interchangeable, but the first is primary).

The current situation with HFAs is that, without changes to make the backend 
aware of the concept, the front-end needs to know the entire sequence of 
previous arguments and how LLVM lowers them to work out how to pass an HFA 
correctly. 

The goal I'd like to see reached is that a front-end should be able to map one 
of its types to an LLVM type and know that if it uses that LLVM type then LLVM 
will do the right thing. As far as I'm aware, this is what happens for other 
targets already (we *are* a bit weird with the HFAs). I think this is 
achievable for the ARM ABI too: LLVM's type system is certainly rich enough to 
capture the distinctions necessary. 

>From Anton:
> I think here stuff should be thought of from different points. While
> providing source type for argument might be beneficial, it might cause
> moving the code from frontend to backend. 

That could certainly go too far, but conceptually it's not necessarily a 
massive problem: if multiple front-ends implement the same ABI calling 
conventions, then perhaps the shared backend is the right place to put that 
common code.

And conversely, I think that if a front-end is worrying about the allocation 
of register numbers then something is a little awry.

But I suppose there will be a substantial cost to implementing this, wherever 
we put it.

> Consider e.g. passing struct
> by value including crazy padding inside. The ABI might specify that
> padding should be removed and struct is passed field-by-field.

To me that would still be a prime candidate for the front-end doing the work: 
it still seems to have an essentially context-free representation as a 
(sequence of) LLVM types.

> Also, note that in many cases the ABI rules are worded in terms of
> source language which might now be preserved during IR generation,
> so...

I'm not sure I follow this point. Is preserving the source language a bad 
thing for some reason I'm missing? Certainly, if it affects optimisation it 
would be.

Tim.