New vtable ABI (was Re: Strange behaviour in C++...)

[Jason Merrill <jason@cygnus.com>]

I should point out here that the proposed mechanism is not the classic ARM
vtable.  In fact, it doesn't have any more space overhead for single
inheritance code than thunks, and may have less for multiple inheritance
code.  It works like this:

Rather than per-function offsets, we have per-target type offsets.  These
offsets (if any) are stored at a negative index from the vptr.  When a
derived class D overrides a virtual function F from a base class B, if no
previously allocated offset slot can be reused, we add one to the
beginning of the vtable(s) of the closest base(s) which are non-virtually
derived from B.  In the case of non-virtual inheritance, that would be D's
vtable; in simple virtual inheritance, it would be B's.  The vtables are
written out in one large block, laid out like an object of the class, so if
B is a non-virtual base of D, we can find the D vtable from the B vptr.

D::f then recieves a B*, loads the offset from the vtable, and makes the
adjustment to get a D*.  The plan is to also have a non-adjusting vtable
entry in D's vtable, so we don't have to do two adjustments to call D::f
with a D*; the implementation of this is up to the compiler.  I expect that
for g++, we will do the adjustment in a thunk which just falls into the
main function.

The performance problems with classic thunks occur when the thunk is
not close enough to the function it jumps to for a pc-relative branch.
This cannot be avoided in certain cases of virtual inheritance, where a
derived class must whip up a thunk for a new adjustment to a method it
doesn't override.

In this case, we will only ever have one thunk per function, so we don't
even have to jump.

Jason