This is the mail archive of the gcc-patches@gcc.gnu.org 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, August 06, 2002 03:04:41 PM -0700 Stuart Hastings <stuart@apple.com> wrote:


that will save even more space that your approach,
Nope (with the addition of my next patch for EH info).
Why do you say "Nope"?  Even with the sibcall optimization, your patch
will cause the compiler to emit code to set the various parameters that
are present in the unified function but omitted in the specialized
version, and will then emit a jump instruction.

With alternate entry points, you can eliminate the jump.

While I agree the "alternate ENTRY points" scheme is architecturally more
elegant than mine, it's not implementable on some targets (e.g.  OS X).
This is a restriction we'd like to relax in the future, but it's a
limitation today; our current object format ("Mach-O") won't support
multiple entry points to a function in a coalesced section.  FORTRAN
functions with multiple entry points aren't coalesced; C++ constructors
and destructors are.
I don't know enough about the Mach-O format to comment on that.  It
would seem to me that one implementation of alternate entry points
would be essentially what you have done; that's how you fake alternate
entry points when you don't really have them.

I'd rather go that way than add a new option only to pull it out when
we get alternate entry points working -- or, even worse, be stuck with
it forever.
My proposed patch is link-compatible with the current cloning scheme;
adding it today and removing it next year should be scarcely noticed.  I
suspect the multiple-entry-point scheme would be externally similar.
Indeed.  That's why I referred specifically to the command line option;
it's user-interface wiggle I'm worried about, not the object-level wiggle.

And the use of DECL_NUM_STMTS here is bogus; you need to check for
triviality in a more robust way.
Certainly.  Any suggestions?  Perhaps an example of a similar test
elsewhere in the sources?
No, there's nothing like that elsewhere.  Why not just have
maybe_clone_body emit the call directly rather than trying to go back
and change things around later?

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


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