[cfe-dev] Passing StructType arguments directly

[John McCall]

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.

> The IR is our primary representation. PNaCl is a project to bring LLVM
> into the browser.

Yes, I know what PNaCl is.

> In order to maintain linkability between
> different front-ends, and to maintain platform ABI compatibility,
> we're setting everything up to use a high-level representation.

LLVM IR is not a high-level representation.  "LL" is right there
in the name. :)  If it's critical that you maintain exact compatibility
with your platform ABI for arbitrary types, you are signing yourselves
up for preserving full C type information through a representation
that does not naturally do so.  Go ahead and read the rules for
passing a struct on x86-64 if you don't see the complexity here.

I don't understand why it isn't sufficient to only guarantee platform
ABI compatibility for a more restricted set of types.  Presumably
native entrypoints are identified in some special way in the
frontend, which you could use to check that the API doesn't
require passing or returning aggregates by value.  You could then
teach your frontends to avoid trying to pass structs by value
on interoperation boundaries, e.g. by always passing structs
indirectly.

John.