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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
