Vcall/vbase offset clarification

[Jim Dehnert]

> From mitchell at codesourcery.com  Tue Jan 25 13:26:12 2000
> 
> Consider:
> 
>   struct A { void f();}
>   struct B : public virtual A {};
> 
> Now, imagine `B' is used as a virtual base.  For example:
> 
>   struct C : public virtual B { virtual void f(); };
>   B* b = new C;
>   b->f();
> 
> The description says:
> 
>   o First, we convert to the most derived class in which `f' was
>     overridden.  That's `A'.  We know statically what offset
>     to adjust `b' by to get an `A*'.
> 
>   o We pass this value to the function found in the vtable for `A'.
> 
>   o That function will first perform the constant adjustment from 
>     `A' to `B'.  
> 
>   o Now, using the vcall offset found in the vtable for `B', the `B'
>     will be adjusted to a `C', and `C::f' will be called.
> 
> I'm not quite sure *why* we do it this way.  Why not just have the
> C-as-A vtable contain a function which adjusts the `A*' directly to a
> `C*'?  I guess we decided we wanted to avoid having to use thunks --
> the current scheme allows the cascading entry point approach.  Was
> that the reason?

Sort of.  I'll explain my (fuzzy) understanding, and let the others
correct me :-).

The real objective is not to completely avoid thunks -- this one could
use either a thunk or a fall-through entry.  But it allows exactly one
thunk/alternate entry, which can therefore always be emitted with the
"original" function and pick up the adjustment via 'this'.  I probably
can't explain why (due to NDA), but placing this alternate entry
immediately before the normal entry will likely have noticible
performance benefit on IA-64.

Incidently, I don't know that we've written it down anywhere, but we
should probably specify that the alternate entry _must_ be emitted with
a virtual function, so other units don't need to consider doing so.
Is this true, everyone?

Hope this helps,
Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272