[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

["hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770

--- Comment #95 from Jan Hubicka <hubicka at ucw dot cz> 2012-04-19 15:07:27 UTC ---
> It is misleading to think that the linker accumulates code in translation unit
> order for a C++ program.  E.g., that is not what happens for template code or
> string constants.  And of course the placement of functions called in different
> translation units is arbitrary.
> 
> A lot of work was done in both GNU ld and gold to move constructors from .ctors
> to .init_array, all to improve startup latency for firefox.  If that same
> amount of work were done on better layout of initialization code, we would
> improve all programs.

I did some work on this, too.  GCC now identify the functions executed only at
startup and global destruction time and puts them into .text.startup
subsections.
This completely elliminate the problem for implicit constructors generated
by #include <iostream>. Those just calls libstdc++ constructor that checks
flags and does nothing most of time.

Sadly I think gold still ignore those, so the optimization works only with
GNU LD.

With more complex constructors this logic helps. It is however not resonable to
assume that ctors execute and access only stuff that can be recognized by
reachability analysis to be only used at startup (after all they are
constructing something).

It is resonable to assume that static constructor in translation unit X will
access functions and variables of unit X (because it is constructing them) + of
course some other common stuff needed to do its job that is shared across rest
of construction process.

For this it makes IMO a lot of sense to make the (implicit to user) order of
execution of constructors match the (impicit) order how sections are laid out.
Sure that there are counterexamples where this does not help, but it is good
heuristics and what we do by default now is almost always the slowest variant.

Firefox is really not a special case here. C++ makes it extremely easy to
introduce
static constructors and destructors and thus most large C++ programs expose
this
problems (at least I know that Chrome and OOo do).

I am not quite sure how linker ordering plugins and code layout is going to
help here better.

Some linkers do automatic reordering based on reconstructed callgraph.
I prototyped code layout pass (ipa-reorder) based on static analysis of the
callgraph at LTO. It works by clustering the callgraph/varpool nodes into
sequences based on the presence of references hoping to get related code
together.

In my tests it however reaches very mixed results on Mozilla, because 
static analysis quickly lose track of virtual calls and use of pointers.

It still seems to me that switching the default ctor execution order, at risk
of breaking non-conforming C++ programs, is a good idea here.  We get
measurable improvements for most of large C++ packages out there and 
hopefully the fallout is not going to be great - many other runtimes
already execute ctors in forwarding order.

We could get the static function/variable reordering pass into GCC,
implement in linker reordering and do reordering based on profile feedback,
but all those are rather ortogonal to the issue discussed here.

Honza