[cfe-dev] Passing StructType arguments directly

Tom Prince tom.prince at ualberta.net
Wed Sep 21 08:27:00 PDT 2011


On Tue, 20 Sep 2011 23:38:03 -0700, Chris Lattner <clattner at apple.com> wrote:
> On Sep 20, 2011, at 4:03 AM, David Chisnall wrote:
> > On 20 Sep 2011, at 06:34, David Meyer wrote:
> > 
> >> * Front-ends would no longer need to implement the ABIs for each
> >> target architecture to get full ABI compliance. They would generate
> >> high-level bitcode, and the ABI lowering knowledge would be contained
> >> in LLVM.
> > 
> > I'd consider this to be a major benefit all by itself.  Not only is the ABI-dependence of the IR a major layering violation, it's also incredibly badly documented.  For example, I know that FreeBSD's x86 ABI returns small structures in registers, but I have no idea how I am supposed to know that this means that {float, float} is returned as an i64 (or why anyone thinks that's even a remotely sane representation in the IR of 'two floats in float registers').
> 
> My read of this thread is that there are two independent things being discussed:
> 
> 1. The utility of a target independent "IR ABI" that nacl wants, and 
> 2. Whether first class aggregates are the way to lower structs.
> 
> #1 is clearly essential for native client, and potentially really
> interesting for other projects.  I tend to agree that FCA's are not
> the right way to get them though.  Have you guys considered just
> having clang scalarize aggregates when they are passed?  There is no
> specific advantage to passing "{i32, i32, i32} %x" instead of "i32
> %x.1, i32 %x.2, i32 %x.3", is there?  The later form would be much
> nicer to the optimizers and code generator.

But this is clearly a mechanical translation that could be handled by a
lowering pass before the optimizers and code generator runs. And when
the native ABI doesn't scalarize aggragates, then it isn't clear to me
how the code generator could then be smart enough to handle this.

  Tom



More information about the cfe-dev mailing list