[cfe-dev] Passing StructType arguments directly

[David Meyer]

Renato,

I'm not sure I understand your suggestion.

The NaCl IRT is compiled with nacl-gcc, which is a modified gcc not
based on LLVM at all. We need to interact (at the native level) with
that code. Even just for X86, this is a problem. On X86-32, the
calling convention implies passing everything on the stack. On X86-64,
the calling convention involves passing things in registers and/or on
the stack according to a complex set of rules based on the original
C/C++ types (AMD64 ABI).

ABI differences like this are normally handled by generating slightly
different bitcode for each target. We don't have this luxury, because
the idea of PNaCl is that we produce a single "platform-independent
executable" which can be run everywhere. We can change what bitcode
the frontends generate, but we can't make that bitcode
target-specific.

So the question is, how do we represent (in a single bitcode file)
enough information about the original C types that we can comply with
both the X86-32 and X86-64 ABIs simultaneously? The answer is we
can't, with today's bitcode. But by using structs as first-class
arguments, we do get closer.

- pdox


On Thu, Sep 22, 2011 at 4:15 PM, Renato Golin <rengolin at systemcall.org> wrote:
> On 22 September 2011 22:25, David Meyer <pdox at google.com> wrote:
>> The problem is that we've been forced into a corner where we're
>> expected to do both: we need a platform independent representation,
>> and we need to satisfy the existing platform ABIs.
>
> Hi David,
>
> Thanks for the long explanation, I think it was really needed.
> Target-independent bitcode will be revisited all the time, and it's by
> identifying the weaknesses of the current model that we can slowly
> walk towards a more generic bitcode.
>
> First, it seems your immediate problem is PCS between NaCl
> target-specific bitcode and PNaCl "somewhat different PCS" bitcode.
> Let's focus on that prblem...
>
> As you said, that can be solved by recompiling everything your way, so
> PCSs match. Is this because the front-end is having different
> assumptions (clang with slightly different target)? Or because it's an
> entirely different front-end?
>
> Supposing you could match the front-end and parameters, would that
> solve your problem? Or would you need a truly independent bitcode for
> the shared bits, so you can lower later to different architectures?
> (I'm not thinking Intel vs. ARM, here, only different flavours or
> Intel).
>
> --
> cheers,
> --renato
>
> http://systemcall.org/
>