From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15355 invoked by alias); 19 Apr 2012 15:15:05 -0000 Received: (qmail 15278 invoked by uid 22791); 19 Apr 2012 15:15:02 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Apr 2012 15:14:15 +0000 From: "hubicka at ucw dot cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them Date: Thu, 19 Apr 2012 15:15:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: other X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at ucw dot cz X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: hjl.tools at gmail dot com X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-04/txt/msg01648.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #95 from Jan Hubicka 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 . 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