B-5 Vtable heuristic

[Jason Merrill]

>>>>> Jim Dehnert <dehnert at baalbek.engr.sgi.com> writes:

 >     B.	The name of the vtable (must be resolved, but may be handled
 > 	separately as part of F-1 mangling).

I think it should be part of F-1.

 > The traditional heuristic is to emit the vtable in the same object as
 > the definition of the first non-inline, non-pure-virtual 
 > member function of the class
  ^--virtual

 > My intuition is that the member functions of most classes are defined
 > in one or a small number of files, suggesting a modification of this
 > heuristic:  Always emit the vtable in a file defining any non-inline,
 > non-pure-virtual member function (or in any file where there are no
 > such member functions defined for the class).

The problem with this is that only (non-pure) virtual functions are
required to be defined.  I suppose we could get around that problem by
limiting it to translation units which use at least one of the class'
non-inline, non-pure-virtual member functions.

However, I don't see a real need to jump through hoops to accommodate
ill-formed code.  All your suggestion would do for bad code would be to
make the linker error message more useful, telling them that the key
function is missing, rather than the vtable.  And that can be done by
post-processing of the linker errors.

The benefit I see to this approach would be fewer copies of the vtable for
classes with all virtual functions inline or pure, but at least one
non-inline, non-virtual member function which is used in most translation
units which also use inline constructors of the class in question.  How
often do we think this situation occurs?

I don't think this is worth the added complexity.

 > 3)  Emission of out-of-line copies of inline routines is a related
 > issue.  They could be emitted in the same file(s) as the Vtable (for
 > polymorphic classes).

I touched on this in my last email about the heuristic.  I am opposed to
emitting the inlines with the vtable, for two reasons:

1) One of our users defines a proxy class whose implementation is not
   exported from the shared library where it is defined; the API for the
   class consists of virtual functions, accessible through the vtable, and
   inline functions.  They complained that since g++ currently emits
   inlines along with the vtable, their code would only link if inlining
   was enabled.
2) Often, we will need 0 copies of inline functions.

 >     E.	Where do we emit inline routines (G-3)?

IMO, in translation units where an out-of-line copy is needed.

 >     F.  Do we put multiple routines in the same COMDAT section?

I don't see how we could.  We could put the vtable and type_info node in
the same section, though.

Jason