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

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:

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

    >> I think that `declares f' was supposed to mean `has an entry
    >> for f in its vtable'.

    Jason> Logically, the two are the same; a class only has entries
    Jason> in its vtable for functions it declares.  The rest is just
    Jason> sharing for optimization.

Yes -- but that's important, right?

I guess I'm not sure what it means to "logically" have a vtable; a
vtable is an extra-lingual construction.  There are vtable entries for
any function in a class, or its primary bases.

    >> 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.  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.

    >> *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. :-) 

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".

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com