[cxx-abi-dev] C++ ABI version 2

[John McCall]

On Nov 29, 2013, at 12:25 AM, Michael Gschwind <mkg at us.ibm.com> wrote:
> John McCall <rjmccall at apple.com> wrote on 11/29/2013 02:28:50 AM:
> On Nov 25, 2013, at 7:05 PM, Michael Gschwind <mkg at us.ibm.com> wrote:
> > > On Wed Nov 20 05:33:31 UTC 2013, John McCall <rjmccall at 
> > apple.com> wrote : 
> > > | Credit the good folks at ARM for these two ideas.
> > > 
> > > I am curious about the history here, because it seems that the 
> > AArch64 ARM ABI appears to drop these changes?  Does anybody have an
> > explanation what transpired to make ARM reconisder and go back to a 
> > more vanilla "industry-standard ABI" (aka Itanium ABI)?
> > > 
> > > Did it turn out that the improvements to be gotten (e.g., by 
> > shaving off a few cycles for reloading this) just wasn't worth the 
> > cost of deviating from the center of gravity for the C++ ABI that 
> > everybody else had, or can we infer more substantial reasons?  (I 
> > think there may still be a few testcase fails for ARM32b due to 
> > different name mangling etc.) 
> > > 
> > > Also, the  iOS ABI on 32b ARM seems to have stepped back from the 
> > full scope of the ARM 32b ABI?   Any thoughts what is pulling these 
> > ABIs back into the  mainline? 
> > 
> > I believe you're over-interpreting the data. :)  Compilers have been
> > very slow to implement any of the changes from the ARM C++ ABI 
> > (except the mandatory change to member function pointers), 
> > essentially because (I believe) no major ARM-based platform has 
> > actually adopted ARM’s C++ ABI in full, essentially because 
> > compilers have been very slow to implement any of it.
> > 
> > The point of this proposal is that, if a vendor is motivated enough 
> > to implement a better ABI when it’s bringing up the compiler for a 
> > new platform, it’d be good to have recommendations for what to do.  
> > And if those recommendations are actually out there and widely 
> > agreed upon, that becomes an inducement for compiler vendors to 
> > implement them, which of course makes it easier for any such new 
> > platforms to adopt them.
> 
> 
> I understand the point you're making, but in the specific example, Apple was the one bringing up a new platform (which is exactly the opportunity point you're referencing) and chose not to do what you describe.

We didn’t when we brought up 32-bit iOS, mostly because, like I said, the compiler didn’t already have that support.  It was not a conscious decision to reject an enhancement; it was, at best, a conscious decision not to take on new feature work in what was already an enormous project.

But we did do this when we brought up 64-bit iOS, perhaps mostly because the rest of the port was comparatively simple, but nonetheless.  As a result, that support is now present in clang, which helps to break the vicious cycle, at least for this change (and a few of the others).

> And, as a kicker, ARM then basically went back on the platform recommendations they had for the 32b ABI when the spec'ed a new ABI for 64b.

You’d have to ask them about their motivations.

> To phrase the question differently, when that platform vendor is to spec a new ABI (like Apple did), are the benefits of the proposed changes sufficient to motivate changes in what is (mostly) a machine-independent part of a compiler, that then has to be maintained separately, and can cause all sorts of distinct maintenance work?

I see your point, but frankly, this kind of maintenance burden is tiny compared to, say, the burden of supporting multiple language dialects simultaneously, which most of the major compiler vendors do.  Plus, like you just said (implicitly), there are no truly machine-independent parts of a compiler; it’s just a question of what you’ve already hooked to allow for idiosyncratic targets.  And the fact that many of these changes were already formally specced for ARM meant that our compiler was likely to have to support them anyway.  Just like anybody else who wants to be able to compile for iOS 64 with perfect compatibility now has to, in fact.

> At what point does a platform vendor like Apple decide to walk down a trodden path - as per precedent - and how high has the payoff to be to forge a new path?

As far as software engineering management questions go, this seems straightforward.  Let’s assume that you actually have to implement the feature yourself instead of piggy-backing on someone else’s work, and let’s assume that you have some spare engineering cycles to pursue general target-specific optimizations.  The question is then: how committed are you to supporting this new platform?  Because if you’re planning to release more compilers for it later, then you’ll get more chances to make minor improvements to the register allocator; but you will never get another chance to fix the ABI.  So you at least have to weigh it higher than you would otherwise.

But frankly, our experience was that this was a very small amount of work to actually implement, on the order of a week of one engineer’s time; most of the cost was in deciding what to do.  For example, we initially considered changing the standard mangling substitutions to privilege libc++, but then we realized that far too many tools make the assumption that demangling is platform-agnostic.  A set of recommendations would therefore have been very helpful, even when paving our own implementation road.

John.