[cfe-dev] Passing StructType arguments directly

[David Meyer]

Chris & Renato,

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.
-
The NaCl project has existed for over 3 years, has a huge team, a
well-tested toolchain (based on gcc), and a bunch of supported apps.
They have a well-defined ABI, and an API for interacting with the
browser (called the "Integrated Runtime" or IRT). On X86 (32 and 64),
the NaCl calling conventions are essentially identical to the usual
Linux conventions, and some of the functions in the IRT require
passing small structs by value.

In comparison, PNaCl is a new idea, with a small team, and an unproven
toolchain.

So right now we're in a pretty bad position. If everybody were already
using PNaCl, not being able to match a specific calling convention
would not be problem, as long as our calling convention was
self-consistent. But as it stands, nobody is using PNaCl, and nobody
really can use PNaCl, because the code we generate on X86-64 doesn't
work (unless you recompile the IRT with PNaCl, and manually install
the new IRT into Chromium, so that the calling convention matches).

This is why we're trying to do some clever lowering of FCA arguments
in the target backends. We can't get full ABI compliance this way, but
if we can get enough to handle the NaCl IRT interface, then PNaCl will
finally work, and we can start moving people over.

But even ignoring PNaCl for a moment...

Much of bitcode's value as an IR comes from its platform neutrality.
Frontend authors don't need to worry about what kinds of instructions
are supported by different processors. They only need to generate
bitcode, and let LLVM figure out how to do the target-specific code
generation.

In that sense, bitcode has achieved 95% platform independence, but
there's that nagging 5% that still requires compiler authors to tweak
bitcode for each target.

This is clearly not the fault of LLVM. The demands on both ends are
unreasonable. The ABI wants information about the high-level type
system, and the language wants information about the target machine.
But even so, it is still a problem that could be solved with a
higher-level IR.

I'm sure we'll revisit this pain in the future. Eventually NaCl will
need to go 64-bit (all of our platforms are currently 32-bit), which
will mean we'll probably want to execute in a 64-bit environment
bitcode that thinks the world is 32-bit.

- pdox