[cfe-commits] [PATCH] Add PNaCl ABIInfo

[John McCall]

On Sep 22, 2011, at 11:14 PM, David Meyer wrote:
> I'm am confused by your objections. Clang already contains a large
> amount of code for satisfying target ABIs. For example, Clang's
> implementation of the AMD64 standard is over 1000 lines.
> 
> PNaCl is no different. We have a specific ABI that must be satisfied
> in order to generate compatible code. Compared to AMD64, the code
> needed to satisfy ours is trivial.

Correct me if I'm wrong, but this "ABI" is a recent invention of yours that
does not currently affect the binary compatibility of any released software.
It is apparently specified directly in terms of what is otherwise an
internal implementation detail of Clang — namely, the IR type that we
translate a struct into.  As we've brought up many times already, this
translation is very lossy and will not be adequate for your purposes
without significant embellishments of the LLVM type system which
many core developers would not be comfortable with.

In short, several of us are objecting to your choice of ABI, which we do
have the right to do, since that ABI is intrinsically intended to be a
permanent constraint on LLVM and Clang.

> I have not seen any proposed alternatives to our current method that
> would satisfy all our requirements.

So, first off, your current method doesn't satisfy all of your requirements,
because it's not capable of being correctly translated into
target-dependent IR.  So there is really no reason to privilege it.

But second off, I have already proposed passing aggregates byval,
which is completely equivalent to your current approach except for not
needing first-class aggregates.  Your target-specific translation pass can
rewrite byval arguments just as well as it can rewrite FCA arguments.
Of course, this suffers from the exact same problem of relying on the
inadequately expressive LLVM type system.

> While our ABI is not 100% finalized, until this patch is committed, we
> can't do any external testing with Clang. (unless we create our own
> branch, which we'd rather not)

I'm sorry, but we do expect code to go through code review, which
includes a thorough review of the underlying motivations and technical
design.

John.