[cfe-dev] Passing StructType arguments directly

[David Meyer]

Dan,

>> 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.

We currently support ARM, X86-32, and X86-64, and we wish to leave the
door open for supporting other targets.

>
> Unions in particular were removed after being added to LLVM IR
> briefly, in part because they never got enthusiasm among major
> contributors.
...
>
> With this approach, you'd still be exposing all of the new type
> diversity to all LLVM IR consumers.

Not necessarily. Imagine having two flavors of IR: high-level (with
extended types), and low-level (without extended types, identical to
bitcode today).

Any IR consumer can choose which form it wants to handle. Given a
high-level module, you can apply the ABI lowering transformation to
get rid of the extended types, and get the low-level representation
instead.

Frontends would only need to generate high-level bitcode, freeing them
of target-specific considerations.

And the backends would only need to worry about processing low-level
bitcode. In particular, CodeGen/Analysis/Transforms wouldn't need to
know anything about the new type system, since the new types would be
eliminated before the bitcode reached them.

- pdox