[cfe-dev] Passing StructType arguments directly

[David Meyer]

Renato,

We completely control the ARM target ABI. PNaCl is the only ARM NaCl
compiler in existence, and there are no plans to develop nacl-gcc
beyond X86.

We're not required to match APCS/AAPCS/AAPCS VFP. Right now, struct
arguments are flattened element-by-element, and the first four
arguments are passed in registers.

For example, right now, if you compile this:

struct foo { int a; int b; int c; };
int bar(struct foo x) { return x.b; }

With -O1, you get this:

define i32 @bar(%struct.foo %x.value) nounwind readnone {
entry:
  %x.value2 = extractvalue %struct.foo %x.value, 1
  ret i32 %x.value2
}

Which becomes a single ARM instruction. (mov r0, r1)

We have the ability to change this, within the limitations of the LLVM
type system, by expanding the struct in different ways in the ARM
target backend.

- pdox


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