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

[Stuart Hastings <stuart at apple dot com>]

On Tuesday, Aug 6, 2002, at 16:54 US/Pacific, Richard Henderson wrote:

> On Tue, Aug 06, 2002 at 04:39:03PM -0700, Stuart Hastings wrote:
> > While this is certainly ugly, the "alternate entry point" scheme must 
> > do
> > something logically similar.
> Not at all.  It sets a variable within the function, and the
> register allocator can decide to put it anywhere handy.  It
> is not restricted to the argument registers.
True enough for destructors.  However, if the users' source for a 
constructor has arguments, the two (or three) constructor entry points 
will have very different signatures (vtt parm), and the users' 
parameters will appear in different registers (PPC) or stack locations 
(x86).  I don't think it's possible to make it target-independent and 
avoid the argument-rippling effect on all targets.

> > It's theoretically possible to re-order the arguments to avoid the
> > argument-rippling effect on PPC, but this perturbs the calling
> > signature and precludes compatibility with the previous cloning 
> > scheme.
> Eh?  What compatibility?  As Jason said, this new unified function
> had better well be strictly local to the object file.  It is an
> implementation detail of the compiler that had better not affect
> the ABI in any way.
Sorry, I confused your question with an unrelated sibcall issue.  
You're right.

I did try this.  I modified the unified structor parameter list to put 
the "in-charge" and "vtt" parameters at the end, but abandoned the 
effort after I realized that

	1) moving the "hidden arguments" to the end of the parameter list 
might be optimal for PPC,
		but pessimal for other, stack-based calling conventions
	2) this is hard when your constructor has variable parameters
	3) it broke an assumption elsewhere in GCC
	4) it's impossible to avoid argument rippling in every case

Pursuant to #1, doing it perfectly for one target (PPC) and badly for 
another (x86) didn't seem like the right thing to do.

I can't recall the exact breakage in #3, but I think that 
some/one/thing else in GCC knew about the parameter signature of that 
abstract, not-to-be emitted function.  I may have fixed it since with 
some changes I made for coexistence with DWARF debugging info.

As for #4, the current scheme provides two constructors, with and 
without a VTT parameter.  If the VTT parameter is present, it's the 
second parameter in the list (IIRC).  If both constructors have 
user-supplied arguments, and are calling a common, "unified" 
constructor, one of the thunk-esque constructors must ripple its 
arguments, regardless of where I put the VTT parameter.

stuart hastings
Apple Computer