vtable notes

[Christophe de Dinechin]

Jason Merrill wrote:
> 
> 
>   C) Ensure that the location of the vcall offset is the same for
>      all secondary vtables

... for non-virtual inheritance only. For virtual inheritance, we need separate
vcall offsets, as you demonstrated. 


> The result of this would be that we would need one thunk, period.
> 
> As I see it, A is a straightforward tradeoff; vtables get larger in the
> case of non-virtual multiple inheritance, but we may be able to reduce the
> number of thunks we use.  On the other hand, we won't be able to fall
> through from a thunk that uses a vcall offset, so we might well end up
> using the same thunks as in the existing design.
> 
> B is a simple improvement to A, reducing the size of the vtables.
> 
> C is the interesting part of Christophe's proposal.  It does sound like the
> result would be faster (by about 2 units of speed) than the existing design
> for calls through obscure bases in large inheritance structures.  However,
> I'm not convinced that there exists a reasonable algorithm for allocating
> vcall offsets in order to achieve this result, in the case of diamond
> inheritance;

In the case of diamond inheritance, we give up that approach and use your vcall
offsets. So I hope the problem does not exist.


> even if there is, it would be much more complex than the one
> for the current design.  This is why I don't think the change could be made
> by tweaking a few words.

The tweaking of a few words I wanted was the following:

1/ Remove the restriction that vcall offsets be allocated only in the presence
of virtual inheritance. Instead, mandate them for virtual or multiple
inheritance.

2/ Change the allocation of vcall offsets so that:
- we allocate one per class when there is no virtual inheritance
- we allocate one per function as soon as there is virtual inheritance.

3/ Discuss how we allocate them (both cases are currently quite unclear, in my
opinion, so we needed to do that anyway.)


Regards
Christophe