Re: [C++ PATCH] ctor vtable vcall offsets

[Nathan Sidwell <nathan at codesourcery dot com>]

Jason Merrill wrote:

> update_vtable_entry_for_fn.  If we override a function from a virtual base,
> we should emit a vcall thunk with the function definition whether or not we
> plan to use it in our own vtable.
Yes, if we *override* it. However this case is `strange' because of the
nearly empty virtual base class optimization.

> Actually, I don't see why we ever need to emit thunks with the vtable.  The
> example in the ABI document is
> 
>   struct A { virtual void f(); };
>   struct B : virtual public A { int i; };
>   struct C : virtual public A { int j; };
>   struct D : public B, public C {};
> 
> But here, calling A::f() means converting to A* then calling through the A
> vtable, so the entry in the C vtable is never used.
hm, maybe you're right.

here's my thinking
A is the (nearly empty virtual) primary base of C, so C's vtable contains
an embedded A table. From g++'s behaviour, it appears to be taking advantage
of that for the virtual call dispatch - I've not checked. If D overrode A::f,
then D would emit a vcall thunk for A::f for the C-in-D vtable, and we'd
be happy. I'm not sure what would be the case when D doesn't override A::f
- should it emit a thunk?

I think you might be right about emitting too many thunks though. I think
we can still have the above optimization (which I guess is important, as it
is one of the major features of the nearly-empty base class optimization), AND
emit fewer thunks, if we have C's vtable emission cause a vcall thunk for A::f
to be emitted. Then D's vtable and ctor vtable emission can make use of it.

I think what I'm saying is that whenever we have a virtual primary base
we should emit vcall adjusting thunks for all functions inherited from the base
heirarchy -- not just those that we overrode. Does that work for you?

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