Virtual function call stuff, again

[Jason Merrill]

>>>>> Christophe de Dinechin <ddd at cup.hp.com> writes:

 > Now, Jim, I just realized that for some reason, in the writeup, the
 > vcall offsets are restricted for "virtual bases" cases. I am unable to
 > implement the "single adjusting entry point" optimization if this is the
 > case. I fixed it in the attached writeup, but I may be wrong.

 > Jason's writeup to B-1 says that you have to implement the vcall offsets
 > even if you don't use them. I don't think we agreed to get rid of them
 > (or is this something else important I missed?)

Apparently so.  Your earlier response to Mark reflects your original
proposal, but what we eventually decided on was significantly different.
The vcall offsets are allocated in the secondary vtable for a virtual base,
one for each virtual function.  Converting from a nonvirtual base uses an
additional entry point.

>From my writeup in the issues list:

We have decided that for virtual functions not inherited from a virtual
base, regular thunks will work fine, since we can emit them immediately
before the function to avoid the indirect branch penalty; we will use
offsets in the vtable for functions that come from a virtual base, because
it is impossible to predict what the offset between the current class and
its virtual base will be in classes derived from the current class.

According to the issues list, we accepted my design at the 12/2 meeting.

Jason