[cfe-dev] Passing StructType arguments directly

Dan Gohman gohman at apple.com
Mon Sep 19 13:35:12 PDT 2011


On Sep 18, 2011, at 5:02 PM, John McCall wrote:

> On Sep 18, 2011, at 3:08 AM, David Meyer wrote:
>> I am surprised to hear that this method of argument passing is
>> discouraged. Do you have a reference, or know the reasoning?
> 
> The problem is that aggregates typically need to be materialized
> in memory;  since that memory is completely abstracted out by
> FCAs, they're actually a very leaky abstraction.  Handling them
> well is just a lot of added complexity for every consumer of IR.
> That's why we try to minimize their use outside of places where
> they're really required.
> 
> I've CC'ed Dan Gohman, who can speak to this more.

One of the big problems with FCAs is that they violate the principle
of LLVM IR that it's supposed to be reasonably efficient code even
when the optimizer misses some opportunities. With FCAs, if the
optimizer accidentally leaves an FCA sitting around in an unlucky
place, the result is a carnival of spilling.

FCAs were invented as a generalization of the earlier multiple return
value feature, where aggregates were first-class in some places and
not in others. The problem FCAs solved was some awkward special
cases and some mild complexity.

First-class aggregates were also motivated by the desire to make
some kinds of front-end code easier to write, though in retrospect
this is dubious.

Because of their awkwardness, FCAs haven't been broadly useful.
They're generally discouraged whenever there's a reasonable
alternative.

In retrospect, the old multiple return value approach was probably
less complex overall, but there's too much inertia behind FCAs at
this point to easily go back.

On Sep 18, 2011, at 7:48 PM, David Meyer wrote:
> The IR is already "tainted" with ABI/C type system hints which are not
> required for correct execution of the bitcode (e.g. "byval", "sret",
> "zext/sext"). I don't see a problem with making this relation more
> formal, to include a little extra type information.
> 
> X86-64's ABI is daunting, but I'm not convinced it is impossible to
> lower this correctly given a few tweaks to the LLVM type system. (for
> example, by adding union and complex types).

While PNaCl may be able to get away with picking x86-64 and ignoring
everything else, LLVM upstream supports multiple ABIs. Platform ABIs
are defined in terms of C types, so unions and complex may not be
sufficient for present and future targets; other things which could
be relevant include signed/unsigned (LLVM's sext/zext aren't
always enough), _Bool, enums, bitfields, special struct members
(packed/aligned/ms_layout/etc.), and complex integer types. These
things were all intentionally excluded from the LLVM IR type system,
for the benefit of consumers.

Unions in particular were removed after being added to LLVM IR
briefly, in part because they never got enthusiasm among major
contributors.

> One idea would be to have a bitcode -> bitcode pass which is
> responsible for lowering the higher-level representations (structs,
> unions, complex) down to simple types, in a target-specific way. This
> includes coercing parameters, expanding va_arg, and so on. This would
> move the target-specific lowering into LLVM and out of the front-ends.
> (This pass would be idempotent)
> 
> To avoid reducing the effectiveness of bitcode optimization, this pass
> would be run (in opt) before the optimization passes. For PNaCl, we
> would skip this pass during opt, trading some optimization in exchange
> for portable bitcode output. We would still need to run this pass
> before the bitcode hits SelectionDAGBuilder, but this could be done
> inside llc, when the target is known.

With this approach, you'd still be exposing all of the new type
diversity to all LLVM IR consumers.

On Sep 18, 2011, at 11:35 PM, John McCall wrote:
> LLVM calls do not seem to incorporate C's undefined
> behavior rules about calling something with the wrong prototype,
> which is good, because the various C/C++ frontends do not always
> agree about how to lower a C prototype into IR.


This is an area where the LL disagress with the VM. The LL
was implicitly allowed to win here for practical reasons,
though that doesn't mean the VM is happy with it ;-).

On Sep 19, 2011, at 12:36 AM, David Meyer wrote:
> Now that you mention it, enforcing prototypes for PNaCl might be a
> good idea, since the behavior is not guaranteed to be portable.

Yes; IMHO, if NaCl is a good idea, it's because it adds new capability,
not because it extends the life of unmainted code.

Dan




More information about the cfe-dev mailing list