Re: [C++ PATCH] ctor vtable vcall offsets

[Jason Merrill <jason at redhat dot com>]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

>>> I think your literal reading is correct though.

Jason> Meaning you agree that we can/should emit all thunks with
Jason> their functions?

> We can, if we read it your way.

Well, looking back over the discussions (closed issue B-1), my original
writeup of the scheme said

  As in Christophe's proposal above, the caller adjusts the 'this' argument
  to point to the class which last overrode the function being called. The
  result provides both the 'this' argument and the vtable pointer for
  finding the function we want.

so you can understand why I read it the way I do.  :)

> But I think we trade away performance when we do that, which was one of
> the major reasons for the whole virtual-bases-can-be-primary thing.
> There seemed to me to be two major benefits:

>   - Space (because we don't have to have another vptr)

>   - Time (because we don't have to convert to the virtual base to
>           do a virtual call)

> You're proposing eliminating the second win, just to avoid emitting as
> many thunks.  But all the thunks are COMDAT and get smushed anyhow, so
> what's the big deal?  In the old ABI we generated lots more thunks
> than we do now -- and even then thunk space was not a big deal for any
> programs I was aware of.

The main problem with third-party thunks is the time penalty for the
indirect branch; that's why we've tried so hard to avoid requiring any.

Furthermore, doing adjustment in the caller is preferable to doing it in a
thunk because it can be scheduled effectively, minimizing the time impact.
Christophe's original proposal didn't use thunks at all for this reason.

>>> *My* beef with the thunk generation scheme (as you know :-) )
>>> was that we didn't just generate thunks everywhere, in COMDAT,
>>> and then allow implementations to DTRT by generating an
>>> overriding strong symbol.  Bizarre SCO linkers aside, I still
>>> like that solution best...

Jason> How about GNU linkers?  I don't think we give priority in
Jason> linkonce resolution to an instance which happens to contain
Jason> a non-weak symbol.

> I thought we did.  But, if we don't, we could. :-) 

True enough.

> It seems like a sensible enough construct.  In lots of places you say
> "this is what to do if nobody says anything definitive".  In at most
> one place, you're allowed to say "this is the definitive answer".

Yep.  Indeed, I suggested a "choose me" flag for the ELF COMDAT groups, but
I don't remember whether or not it was accepted; I think some people wanted
to be able to just choose the first copy encountered (i.e. the SCO
behavior).  Anyone know where to find a copy of the evolving ELF spec?

But I still don't see what the problem is with just emitting the thunks
with their functions.  Especially now that you've got it mostly
implemented; why would you want to go back?

Jason