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

[John McCall]

On Sep 26, 2011, at 5:42 PM, David Meyer wrote:
>>> 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.

I understand.  I don't really have a good answer for you.  My worry is
that (1) you're assuming a lot about how frontends translate C/C++
struct types into IR and (2) that translation isn't injective and will never
be able to be perfectly reversed.

I can tolerate an ABI dependence on Clang's translation of types into IR
if you are willing to promise me two things:
  A)  You only really care about the translation of a fixed and small
    number of types.
  B)  You have looked at how all of those types are translated into IR,
    and the translation is perfect;  they are all translated into LLVM struct
    types with exactly the right members.

If you can only promise A, then we can work on B and try to get it right.
If you can't promise A, then I think you have a problem which needs to
be solved properly before you make promises we can't keep, and I'm
only sorry that it's not going to be an easy problem.

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

Yeah.  Again, I'm not really defending the current setup;  I'd be much
happier with a system where we could pass structs "by value" in a
high-level way, only special-casing truly special things like transparent
unions and C++ classes with nontrivial copy constructors.  But that's
not what we have, and we're a lot of design away from anything like it.

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

I think there might have been a miscommunication.  You already have
a pass that rewrites call sites and function declarations, right?
Something that runs before the backend ever sees IR, breaking up
aggregates, introducing byval slots, etc. as required by the host
platform's ABI?  I was just suggesting that you teach that code to
work on byval arguments and parameters instead of FCA arguments
and parameters.  If anything, that's probably less work, because hey,
sometimes you really do want a byval argument.

John.