[LLVMdev] [llvm-commits] [cfe-commits] [Patch?] Fix handling of ARM homogenous aggregates
Tim.Northover at arm.com
Tue Apr 10 04:45:37 CDT 2012
> 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
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.
> 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
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,
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
More information about the LLVMdev