[C++ PATCH] ctor vtable vcall offsets

[Nathan Sidwell]

Jason Merrill wrote:

> But with Java interfaces we can assume no adjustment is necessary, since no
> adjustment is ever necessary.  With C++ virtual bases, we can't.
You'll need to adjust to the (virtual) base that is the interface class, 
in order to lookup the function in that vtable. However, you know that the
function will have been overridden by the class providing the implementation
and that'll adjust the self pointer back again. Interesting.

> I assume it means that A may not be a proper base of B; that is, it may be
> B itself.  Since that is also said by the second parenthetical note, the
> first should probably be removed.
oh yes - still should be removed, because the abi glossary says 'base' can mean
the class itself, `proper base' excludes the class.

> Yes, but if it isn't overridden, going through the thunk you propose is
> also a waste of time--and a *lot* more time than the adjustment in the
> caller, which can often be scheduled away.
ok.

> And I believe the time savings you mention are not significant enough to
> justify complicating the implementation to deal with this special case,
> especially given the problems with third-party thunks.
ok. I think we've got the position that there is insufficient data to be
convinced either way. However, if we do emit a third party thunk and have
the base part of the vtable set up correctly, we can leave it to the calling
code to make the choice. It can either convert to the last base which
overrode, thereby guaranteeing no use of a third party thunk, or it can
just use the base part of the vtable and risk it. Different architectures
will have different costs for either choice - we shouldn't constrain
implementations unnecessarily. A compiler could add profiling
feedback to determine if a third party thunk caused a performance penalty for
each call site.

So, here is my proposal.
1) When a class hierarchy has multiple uses of a primary virtual base, the
(secondary or virtual) bases which lose that primary fill in the base part of
their vtables completely, referencing (third-party) vcall thunks, if needed.
2) 3.2.4 is amended to indicate that where a virtual primary base is involved,
there is a choice. Either convert to the virtual base that exists in the
complete object, or simply use the sub vtable.
3) Where does the third party thunk get emitted? We could leave it to the
usage point, or we could force its emission when emitting the vtable of the
class which has the virtual primary base (that class won't use the thunk, but
any class deriving from it might need the thunk). I have no strong opinion
either way, though emitting with the first use vtable seems neater.

Does this work for everybody?

nathan
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org