[PATCH] C++ space optimization: de-cloning con/de/structors
Stuart Hastings
stuart@apple.com
Tue Aug 6 18:08:00 GMT 2002
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
More information about the Gcc-patches
mailing list