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] Option to declone constructors and destructors in C++ (space optimization)


William Maddox wrote:
> This patch implements a compiler flag to enable sharing
> of code between the in-charge and not-in-charge variants
> of C++ constructors and destructors.  It is based on an
> earlier submission by Stuart Hastings, updating his patch
> for the current trunk and making a few minor improvements.
> 
> Given the previous history of Stuart's patch, I am a bit hesitant
> to reopen this can of worms.  The included patch has been
> shown, however,  to produce worthwhile space savings on some
> real-world applications.  For what it's worth, here it is...

I certainly appreciate the space savings, but I don't think this is a
good idea.  For starters, I don't think we should be encouraging folks
to go around the ABI; either we should extend the ABI via consultation
with the other stakeholders, or we should stay within it.

I also think that the right fix for this, within the scope of the ABI
itself, is just to bite the bullet and implement multiple entry points
in the middle-end.  Most of the core optimizers will handle this, or can
be made to do so relatively easily; after all, multiple entry points are
not much different from an analysis perspective that a single entry
point with non-deterministic edges to all of the entry points.

There would certainly be some work to define a tree representation of
multiple entry points.  My suggestion would be a FUNCTION_DECL for each
entry point.  We'd have a canonical FUNCTION_DECL for each function;
other entry points would have a DECL_ENTRY_POINT_FOR pointer back to the
canonical version.

The nasty bits are probably on the RTL side.  We'd have to generate
prologue code for each entry point, or arrange for sharing.

This would also allow the fall-through optimizations contemplated by the
C++ ABI for thunks, where, for example, you implement a +16 thunk by
adding 8 to the "this" pointer and falling into the +8 thunk, which
itself falls into the main function.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


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