[C++ PATCH] ctor vtable vcall offsets

[Jason Merrill]

>>>>> "Nathan" == Nathan Sidwell <nathan at codesourcery.com> writes:

> Jason Merrill wrote:
>> But with Java interfaces we can assume no adjustment is necessary, since no
>> adjustment is ever necessary.  With C++ virtual bases, we can't.

> You'll need to adjust to the (virtual) base that is the interface class, 
> in order to lookup the function in that vtable. However, you know that the
> function will have been overridden by the class providing the implementation
> and that'll adjust the self pointer back again. Interesting.

Actually, you never have to adjust at all, as Java only has single
inheritance.  The vtable for the interface may not be at offset 0, but that
only affects looking up the function pointer, not what you pass to it as
'this'.

>> And I believe the time savings you mention are not significant enough to
>> justify complicating the implementation to deal with this special case,
>> especially given the problems with third-party thunks.

> ok. I think we've got the position that there is insufficient data to be
> convinced either way.

I think that there is a tradeoff to be made, but that we need to decide one
way or another, just as with so many other areas of an ABI.  No one
solution will be completely optimal for all situations, and we can't have
special cases for every possible case.

> However, if we do emit a third party thunk and have the base part of the
> vtable set up correctly, we can leave it to the calling code to make the
> choice. It can either convert to the last base which overrode, thereby
> guaranteeing no use of a third party thunk, or it can just use the base
> part of the vtable and risk it. Different architectures will have
> different costs for either choice - we shouldn't constrain
> implementations unnecessarily. A compiler could add profiling feedback to
> determine if a third party thunk caused a performance penalty for each
> call site.

I disagree.  Apart from the performance aspect:

1) A standard should not try to be all things to all people.  We should not
   burden implementations that make one choice by making them emit code to
   support implementations that make another choice.
2) Emitting third-party thunks with the vtable adds unnecessary complexity
   to the implementation.  g++ would be simpler without all the
   GENERATE_THUNK_WITH_VTABLE logic.
3) This situation is likely to be quite rare--in practice, usually either C
   will override the function, or we won't call the function through a C*.
   It just doesn't make sense to me to add this sort of special case,
   possibly slowing things down, to deal with an unlikely situation.

The virtual calling convention was one of the first items to be resolved in
the ABI process; we discussed the tradeoffs, and decided to go with thunks
immediately before the function.  I'd really rather not reopen that
decision now.

I'm sorry I didn't catch this when Mark first suggested that we would need
third-party thunks in some cases.  But we don't actually need them after
all, and I would really like to do away with them.

Jason