[cfe-dev] [cfe-commits] [PATCH] Add PNaCl ABIInfo

[David Meyer]

John,

>> How Clang translates a struct to IR is not an internal implementation
>> detail of Clang. It is very much driven by the target ABI. In many
>> cases, you have no choice. The platform ABI forces you to lower
>> structs in a certain way.
>
> Other platform ABIs are not specified in terms of LLVM IR types.  This
> is very much part of my objection to what you're doing.

The PNaCl platform *is* IR, so we have no choice but to define our ABI
in terms of what the IR looks like.

The native platform ABI is an implementation detail which is hidden
behind llc, which runs inside Chromium and is under our control.

>
> Most platform ABIs just care that we emit code that gives the overall
> object a specific size and minimum alignment and that places various
> sub-objects at specific byte offsets within the object.  In Clang, we can
> make that happen in whatever way we please.  For example, we can
> emit structs as [N x i8], use explicit alignments everywhere, and use
> bytewise GEPs and bitcasts to get this result.  We certainly *try* not to
> do that, but there are situations with unions and C++ class layout
> where we don't always have a more satisfying choice.

You are forced to generate IR which will make the backend generate
calls conforming to the native ABI.
This is a leaky abstraction, since it requires the frontend to know
about how the backend lowers IR arguments to native code.
The fact that there are multiple ways to do it is hardly a useful feature.

> The use of FCAs is really far less important than the extremely
> cavalier approach towards ABI compliance.  I want that problem to be
> solved well, not turned into an endless set of bugs because you kept
> punting it and assuming it would work out until it suddenly started to
> matter.  And I would like it to be solved before you actually release
> this and turn an off-hand decision into a permanent constraint.

We have a very good idea of the ABI we want to have. FCA have worked
well for us, and we are happy to continue using them. You are the one
who is calling into question our ABI decision.

Regarding byval, for the sake of argument, we tried it your way, to
see what would happen.

We discover that ARM's support of byval is shaky at best. We've
already discovered three major bugs. Since the front-ends usually
don't general byval on ARM, it is not considered supported. They have
taken steps towards removing support for it entirely.

What are we suppose to do about that? We don't have the luxury of
emitting different IR for each target backend.

- pdox