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

[Jason Merrill <jason at redhat dot com>]

On Wed, 7 Aug 2002 16:06:50 -0700, Stuart Hastings <stuart@apple.com> wrote:

> On Wednesday, Aug 7, 2002, at 15:36 US/Pacific, Jason Merrill wrote:
>
>> On Wed, 7 Aug 2002 14:37:19 -0700, Matt Austern <austern@apple.com> wrote:

>>> 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.
>
> Why?  The "thunk" still looks like a normal function at the tree stage,
> making it and its call to the unified structor both typical inlining
> candidates.  The sibcall optimizer turns the former clones into thunk-oid
> things later.

Because we don't want to make the unified *tor part of the ABI.  If we
inline the thunks, they depend on the unified version.  But I suppose this
isn't really any more complicated than the template case.

>> On Wed, 7 Aug 2002 14:34:06 -0700, Stuart Hastings <stuart@apple.com>
>> wrote:
>>
>>> Hmmmm.  This is scary; we had a miserable experience with an early
>>> version of the de-cloner that didn't properly invoke copy-constructors
>>> for arguments.  Sometimes this really does make a difference... :-)
>>> Anyway, the use of 'current_function_is_thunk' in gcc/gcc/calls.c
>>> appears to be smart enough to DTRT, and I'd be happy to set
>>> 'current_function_is_thunk' right now except for that bitter memory.
>>> Would it be O.K. to defer this optimization for a while?  I'd be
>>> happier if this change survived a complete OS X build, or at least, a
>>> very fussy copy-constructor testcase.
>>
>> I think it's better to work any bugs out now.  If you want to be
>> conservative with your internal tree, that's your perogative, but when do
>> you think breakage will be more acceptable?
>
> If my "deferred optimization" is your "bug," then there are a *lot* of
> related bugs in GCC right now.  :-)

No, the "bug" I'm referring to is whatever you're worried about that causes
you to want to defer this simple change.  I'm saying we shouldn't defer it
just because you think something might break.  That's what testing is for.

>>> BTW, if a given constructor needed to use a copy-constructor for some
>>> random argument, it might get a non-inlined call to that
>>> copy-constructor, implicitly revoking its standing as a "thunk."  Will
>>> this always work correctly with the target-dependent code in rs6000.c
>>> and alpha.c, or would the de-cloner be responsible to detect this when
>>> it happens and clear "current_function_is_thunk" ?
>>
>> The point of current_function_is_thunk is to avoid re-copying args passed
>> by invisible reference, and instead to just pass the pointer on through.
>> There shouldn't be any copy constructor calls.
>
> But there are.  Real users write real constructors that expect
> objects-passed-by-value that must be copied by a copy constructor.

Absolutely.

> And when such a constructor is de-cloned, it cannot be a thunk-ed by the
> sibcall optimizer.

Why not?  These objects, created by copy constructors, are passed to the
thunk by invisible reference.  The thunk can just pass the reference along
to the implementation.

> Perhaps the sibcall optimizer could recognize when it has reduced a
> function to a thunk, and set "current_function_is_thunk" for us?

No; the sibcall optimizer can't tell when a copy constructor is or is not
required.  Given

  void f (A);
  void g (A a) { f (a); }

the compiler is not allowed to optimize away the copy constructor call.
Similarly, in the case of the decloning thunks, the compiler is not allowed
to add new copy constructor calls.  So this is a correctness issue, not
just an optimization.

Jason