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

[Matt Austern <austern at apple dot com>]

On Tuesday, August 6, 2002, at 03:18 PM, Mark Mitchell wrote:

> > 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.
Are we currently using multiple entry points for anything other than
the Fortran ENTRY statement?

I agree that multiple entry points are very useful for a lot of 
purposes,
and I also agree that multiple entry points are the way that we ought
to implement the C++ ABI requirement of multiple entries for
constructors and destructors.  Just seems to me that we need a bit
of infrastructure for multiple entry points before we use them: we
need to test linker capabilities in the configure script, and we need
low-level platform-dependent code to actually generate them.  (Since,
as you point out, different linkers will need to deal with them in 
different
ways; in general it's not so simple a matter as spitting out more than
one label.)

I'm wondering how much of that infrastructure already exists.  If the
answer is that a lot of it isn't there yet, then maybe we should take
Stuart's patch in the mean time.

The MACH-O issue, incidentally, is that users can tell the linker to
reorder symbols to improve locality.  When users do that, the linker
assumes that any glob of code between two external symbols may
be moved around without regard to any other such blob of code.  So
if there's a function with an external symbol in the middle, and
someone uses that linker flag, then the linker will rip the function in
half.  I don't know if any other platforms have this exact same issue,
but I would imagine that there are other platforms where multiple
entry points are more complicated than just putting another external
symbol somewhere in the middle of the function.

			--Matt