This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] C++ space optimization: de-cloning con/de/structors
- From: Stuart Hastings <stuart at apple dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 6 Aug 2002 15:04:41 -0700
- Subject: Re: [PATCH] C++ space optimization: de-cloning con/de/structors
On Tuesday, Aug 6, 2002, at 13:20 US/Pacific, Mark Mitchell wrote:
This patch essentially un-does the cloning operation. The original
function gets renamed to something that can be un-mangled
Note that Zack recently checked in better support for alternate entry
points. What we really want to do is use alternate entry points;
Hmmm, sounds like you've already made up your mind. :-(
that will save even more space that your approach,
Nope (with the addition of my next patch for EH info).
and be faster as well.
Nope; they should be very similar.
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'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.
If people want your optimization in the mean time, I'd
actually be happier without the command-line switch; then we don't have
the user interface weirdness.
O.K.
You need to get rid of the #if 0'd code
O.K.
and add documentation if we do want to keep the switch.
I'd be happy to remove it; we added the switch mainly to aid in
debugging.
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?
stuart hastings
Apple Computer