[cfe-dev] Passing StructType arguments directly

[Renato Golin]

On 23 September 2011 04:18, David Meyer <pdox at google.com> wrote:
> Sandeep,
>
> Theoretically, in the future, the official IRT would be built by
> PNaCl, so that any native code would need to match our ABI.
> Furthermore, if we can demonstrate that we can match the performance
> and reliability of the nacl-gcc toolchain, we could legitimately
> require every vendor to switch to PNaCl.

Hi David,

I find it difficult to believe that you can get a target-independent
PCS *and* improve performance.

As Sandeep said, ARM has it's own sub-architectures (APCS, AAPCS,
AAPCS VFP) which are more similar to AMD64 than x86. The only way to
be truly independent is to follow the base standard, which is to put
everything on the stack, and that, well, produces very bad performance
(or at least, is harder for the compiler to optimise, I'd guess).

This topic was discussed in the European meeting, and I've heard two
options to link the language-specific features with target-specific
ABI:

 1. To annotate IR

This is not the best idea ever, and many optimizations can remove
metadata and break the lowering. The alternative would be to create
special keywords (like values_in_regs_pcs, values_in_vfp_regs_pcs,
etc) to become a bit more platform-independent. That would work on
some cases, but I'm not sure of all the implications.

 2. To have special call-back functions

Those would be a set of libraries that know how to connect A -> B. So,
you could generate your IR and flag that module as "C++" (A = C++),
and the back-end would try to lower to x86 (B = x86) and pull the
library/sub-function LowerAtoBPCS(). For that, you just need the
original language annotated somehow (global metadata, magic global
variables, add it to the triple, etc), since the back-end already fill
the latter part.


Another alternative, for you, would be to have multiple copies of NaCl
objects (compiled with nacl-gcc) and being able to dynamically select
at runtime, which one you're going to link against. If both nacl-gcc
and clang follow the same PCS, that should just work.

cheers,
--renato