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

[Nathan Sidwell <nathan at codesourcery dot com>]

Mark Mitchell wrote:

>   - Space (because we don't have to have another vptr)
> 
>   - Time (because we don't have to convert to the virtual base to
>           do a virtual call)
This was my understanding too. I thought the primary motivation for the
nearly-empty virtual base optimization was for things like Java interfaces
which are such objects (or their equivalent in a C++ heirarchy). Indeed the
ABI doc says as rationale in 2.4 II
	In case (2b) above, the use of the first indirect primary base class
	as the derived class' primary base does not save any space in the			object, and will cause some duplication of virtual function pointers
	in the additional copy of the base classes virtual table. The
	benefit is that using the derived class virtual pointer as the base
	class virtual pointer will often save a load, and no adjustment to
	the this pointer will be required for calls to its virtual functions
Also,
    3.2.4 Caller

   When calling a virtual function f, through a pointer of static type
   B*, the caller
     * Selects a (possibly improper) subobject A of B such that A
       declares f. (In general, A may be the same as B.) (Note that A
       need not define f; it may contain either a definition of f, or a
       declaration of f as a pure virtual function.)
What does 'improper base' mean here? There's no definition of that term.
I took it to mean this virtual primary base thing which might have been
lost to some other class in the heirarchy, but our vtable still has
the right bits in it.

Jason Merrill wrote:
> The main problem with third-party thunks is the time penalty for the
> indirect branch; that's why we've tried so hard to avoid requiring any.
By indirect branch you mean you call the thunk which then has to branch
to the function as it can't be laid out just before hand?

If so, you *only* get that constraint on the thunk layout within heirarchies
that have lost a primary virtual base. Now, as Mark says, adjusting
to the virtual base might well be a waste of time, if the function had
been overridden further down the hierarchy - in that case, the overrider
will have emitted vcall adjusting thunks for all the base vtables which
contain the entry. As those can be emitted with the overriding function,
they can run into that function have no second branch. If the function is
not overridden down the heirarchy, then we have to have a vcall adjusting
thunk which adjusts the this pointer to the real instance of the virtual
base within the dynamic type of the object. The possibility of that thunk's
existance known as soon as we have a class with a virtual primary base.
It can be emitted once there, but not sooner.

Now back to the Java interface case. Interfaces have no implementation, so
the virtual functions must be overridden in the class inheriting the
interface - so the second half previous paragraph does not apply. That part
can only apply in C++, and I believe it to be a sufficiently rare case as to
not be a valid reason to forego the time saving the nearly empty
virtual base class optimization gives you in the usual case.

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