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

> 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.

Hi Tim
> 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.
Let's consider one example:

union {
  float foo[4];
  int bar[3];
};

This is definitely not a HFA. However, such a union can be represented
via several different things in LLVM IR: [4 x float], [4 x i32], [32 x
i8] (all involving bitcasts to access one of the fields of a union).
And here we have a problem: 4 x float can be thought as HFA at IR
level, however it's certainly not since the HFA rules are worded using
C-level constructs and not IR-level.

So, my point is that IR is not expressible enough to capture all
source information necessary to model ABI properly. Do you have good
solution for this problem?

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Tuesday 10 Apr 2012 21:35:55 Anton Korobeynikov
wrote:
> Hi Tim
> 
> > 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.
> 
> Let's consider one example:
> 
> union {
>   float foo[4];
>   int bar[3];
> };
> 
> This is definitely not a HFA. However, such a union can be represented
> via several different things in LLVM IR: [4 x float], [4 x i32], [32 x
> i8] (all involving bitcasts to access one of the fields of a union).
> And here we have a problem: 4 x float can be thought as HFA at IR
> level, however it's certainly not since the HFA rules are worded using
> C-level constructs and not IR-level.
I'd say the bulk of the ABI is specified in simpler terms than the C
language,
much closer to LLVM's IR (in fact, in at least one respect higher level than
C: arrays can be first-class argument types). 

Only after the actual rules have been given does the ABI say what the C/C++ 
mapping to these concepts is. Presumably other languages that want to be 
compatible will define their own mapping. It's a two-phase approach which 
seems fairly well-suited to LLVM's IR and structure.
> So, my point is that IR is not expressible enough to capture all
> source information necessary to model ABI properly. Do you have good
> solution for this problem?
I think it's expressive enough to provide an interface for each category the
ABI cares about though:
    + Integer types of various widths and alignments.
    + Floating types, similarly.
    + Vectors as above.
    + Composite types that are HFAs.
    + (In the 64-bit case) Composite types less than 16 bytes in size.
    + Non-HFA, non-small composite types.

In this example I'd say clang's job (ideally) would be to represent the
union
using some type in the final category ([4 x i32] is probably sufficient in the 
32-bit world right now, because it turns out the ABI doesn't care about 
splitting between registers and stack).

This kind of issue is always going to be present: any front-end is going to 
have to lower its internal representation to some LLVM type and discard 
information doing so, but I think it's neater if that's all it has to
do.

We should have a chat about this at the conference later. I'm in favour of
the
backend solution, but could certainly live with the other. I think deciding 
the correct approach is the most important thing.

Tim.