Alternate picking virtual bases to share vptrs.

[Jason Merrill]

>>>>> Coleen Phillimore <coleen at zko.dec.com> writes:

 > Jason had a good point about virtual base dominators, since (below)
 > Concrete1 dominates Interface1,2,and 3, it appears that virtual function
 > calls to 'foo' first convert to a Concrete1 before being called.  So in
 > this case, there's no point in sharing the vptr of Interface1 2 or 3
 > with the Most_Derived class.  (Correct me if I'm wrong about this
 > please, this is all experimental).

Actually, I disagree.  Let's consider:

A) Interface1 (or 2, 3, 4) is the primary base of Most_Derived
B) Interface1 is not the primary base of Most_Derived.

1) Calls to Interface1 functions overridden by Most_Derived
2) Calls to Interface1 functions overridden by Concrete1 and not Most_Derived

----

A) M_D gets I1's vtable at offset 0.
B) M_D gets its own vtable at offset 0.

A) Converting to I1 is a nop.
B) Converting to I1 requires a load from the vtable.

1A) The call requires no conversion.
1B) The call requires a load from the C1 secondary vtable.

2A) The call requires a load from the C1 secondary vtable.
2B) The call requires a load from the C1 secondary vtable.

----

It seems to me that choosing one of the virtual bases to be primary is a
definite win.

 > Pick the first virtual base class in dfs order (I vote no
 > declaration order on the base class specifier list) that's not a
 > primary base class of any subobject of derived class to be
 > the primary base class of the derived class.  If there is no such
 > virtual base class, don't pick one.

I would change this to:

Pick the first mostly-empty virtual base class in dfs order that is not
already at a fixed offset in M_D (i.e. not already the primary base of a
non-virtual base).

Jason