[cfe-dev] Passing StructType arguments directly

[Amara Emerson]

Agreed. General consensus seems to be that frontends have no business, nor
should they be required to have this tight coupling with the target
information. As far as I can tell, a new target independent ABI component
would also solve the issues raised in the developer meeting talk as well.

FCAs, as they currently exist for structs, aren't the right solution and
will have to go to achieve this. For ABI independence, I think there needs
to be a higher abstraction type that is handled more intelligently in
targets.

Amara

On 21 September 2011 08:04, John McCall <rjmccall at apple.com> wrote:

> On Sep 20, 2011, at 11:38 PM, Chris Lattner 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.
>
> Yeah, to be clear, I think this is a great goal.  I would love it if we
> could get frontends out of the business of doing bizarre ABI lowering around
> calls.
>
> John.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110921/4748a391/attachment.html>