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

[Stuart Hastings <stuart at apple dot com>]

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:
>
> > On Wednesday, August 7, 2002, at 02:34 PM, Stuart Hastings wrote:
> > > I asked Matt Austern (conveniently in the adjacent office :-), and he
> > > asked: Is private linkage appropriate for unified constructors 
> > > invoked by
> > > "static inline" or "template" constructor thunks?  (Sorry, that 
> > > question
> > > is a mouthful.)
> > 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.
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.

> Templates shouldn't be a problem; they still have the usual entry 
> points.
>
> > Genuine question, not a rhetorical one.  I don't remember whether
> > the usual vague linkage mechanism depends on external linkage.
> Yes, definitely.
>
> On Wed, 7 Aug 2002 14:34:06 -0700, Stuart Hastings <stuart@apple.com> 
> wrote:
>
> > On Tuesday, Aug 6, 2002, at 16:24 US/Pacific, Jason Merrill wrote:
> > > I also think you want to set current_function_is_thunk to avoid 
> > > re-copying
> > > arguments.
> > 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.  :-)

> > 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.  And 
when such a constructor is de-cloned, it cannot be a thunk-ed by the 
sibcall optimizer.  De-cloning can still win on space in this situation.

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

stuart hastings
Apple Computer