B-1 vtable layout

[Jim Dehnert]

Jason noticed an issue today that we want to raise for those who weren't
at the meeting, involving the layout of primary vtables.

Our chosen layout starts with the primary base class vtable layout (if
any), and adds additional vbase/vcall offsets to the beginning, and
additional vfunc pointers at the end.  It is then followed by the
secondary vtables, in inheritance graph order.

We have assumed, for instance in our decision not to propagate vbase
offsets from non-virtual bases, that the secondary vtables were directly
accessible at compile-time offsets from the primary vptr.  However, this
is not currently the case if we are dealing with a class that is the
primary base of a derived class.  The derived class's additional vfunc
pointers will be added between the base class vtable and its secondary
vtables for the base's base classes.  Therefore, non-overridden base
class member functions, at least, can't make assumptions about
secondary vtable offsets.

One can, of course, get to the secondary vtable via the secondary vptr
in the object, but that costs an additional load.

There is a "solution" that should work, but is a touch ugly.  That
would be to place the additional vfunc fields for the derived class
not immediately after the primary base vtable, but after all of its
non-virtual secondary vtables.  If we don't think this is worthwhile,
we should reconsider the decision about promoting vbase offsets.
(I still wouldn't choose to, but we should make the choice conscious
of the real implications.)

Jim
-		Jim Dehnert  x3-4272