Re: [PATCH] C++ space optimization: de-cloning con/de/structors

[Jason Merrill <jason at redhat dot com>]

On Wed, 7 Aug 2002 15:42:45 -0700, Matt Austern <austern@apple.com> wrote:

> On Wednesday, August 7, 2002, at 03:36 PM, Jason Merrill wrote:
>>> Sorry, I should've just asked this myself.  My question wasn't about
>>> static
>>> inlines, but about extern inlines (the default).
>>>
>>> The problem, of course, is that we might have an inline (or template)
>>> constructor in multiple translation units; we're required to only have
>>> a single copy after we do the link.  Would this conflict in any way with
>>> giving constructor bodies internal linkage?
>>
>> It would mean trying to inline the thunk which calls the unified
>> constructor would be rather complicated.  I would think you just wouldn't
>> de-clone inline *tors.
>>
>> Templates shouldn't be a problem; they still have the usual entry points.
>
> Hm, I don't think I follow that.  Templates use vague linkage.  If
> vague linkage depends on external linkage, then I think that means
> that we can't change a decloned template constructor to have internal
> (or no) linkage.
>
> I think I must be missing your point.

The ABI-specified entry points have vague linkage, as usual.  As an
implementation detail, they call a function with internal linkage.  As far
as the ABI is concerned, the unified *tor doesn't exist.

Well, hmm.  I suppose there is a question about eliminating duplicates in
the case of templates.  Having internal copies of the unified *tor all over
the place would be a waste, but if we put it in a COMDAT group, that has ABI
impact.  I suppose this could be another case of "the ABI doesn't say you
should do this, but it says what it should look like if you do", like
allocating ctors.

In 5.2.5 the ABI says

  Implicitly-defined or inline user-defined constructors and destructors
  are emitted where referenced, each in its own COMDAT group identified by
  the constructor or destructor name.

This seems to mandate putting the different *tor variants in separate
sections, which would prohibit the multiple entry point implementation for
*tors with vague linkage.

And indeed, it occurs to me that using multiple entry points would be
beside the point.  IIRC the original reason for splitting the *tors up like
this was to avoid pulling the free store management code into programs that
never use new/delete; this would be defeated by either this decloning
transformation or use of multiple entry points.

A better solution, it seems to me, is to factor the *tors properly.  The
base ctor is a subroutine of the complete ctor, which is a subroutine of
the (optional) allocating ctor.  The base dtor is a subroutine of the
complete dtor, which is a subroutine of the deleting dtor.  Then it becomes
a question of inlining, rather than cloning.

What do y'all think of moving in that direction instead?

Jason