This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]