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

[Tim Northover]

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.