Virtual Calls: Make the ABI match the implementations

[Mark Mitchell]

>>>>> "Jason" == Jason Merrill <jason at redhat.com> writes:

      Jason> I agree, but it seems to me (judging from the amount of 
      Jason> innovation in this ABI) that we decided long ago not to 
      Jason> give a lot of weight to difficulty of
      Jason> implementation.  Perhaps that was the wrong decision, but 
      Jason> it's a bit late to reconsider now.

Perhaps.  Christophe and I came up with this suggestion because it
doesn't actually remove any of the benefits of the innovation.  For
example, allowing virtual bases to be primary is a major change in
everyone's compilers -- but it does also provide a big win for some
code.  By simply mandating that compilers put out the old-style
thunks, we'd cost only space in .o's -- a good compiler can override
with the new-style thunks (modulo the linker issue you raised), and
then the final executable will be precisely the same as currently
specified.

So, all we're suggesting is easing things for implementors without
limiting the performance gains from the ABI at all.

    Jason> And I'm a bit puzzled why this issue is coming up with
    Jason> respect to this particular detail; it seems pretty easy to
    Jason> determine what thunks to emit with the function.  The

It's not that -- it's the fact that the thunks you have to emit have a
pretty different form from the usual thunks.  They have to look at
vcall offsets too -- not just make the usual single this adjustment.

The reason this particular issue is coming up (as opposed to, say,
vcall offsets or virtual bases as priamry bases) is that it tends to
impact compiler back-ends much more than most of our other changes.
In a lot of organizations, the back-ends are much more separate from
the front-ends than they are in GCC -- for example, maintained by an
entirely different group with different management.  Interfaces
between front-ends and back-ends have to change, optimizers have to be
revalidated, all tools that process the back-end representation have
to be recompiled, etc.

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com