From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8805 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] configure: add gcc flags for better link-time optimization Date: Mon, 2 Nov 2015 19:01:07 -0500 Message-ID: <20151103000107.GO8645@brightrain.aerifal.cx> References: <1445603426-4827-1-git-send-email-vda.linux@googlemail.com> <20151101195658.GL8645@brightrain.aerifal.cx> <20151102223648.GN8645@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1446508890 15006 80.91.229.3 (3 Nov 2015 00:01:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Nov 2015 00:01:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8818-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 03 01:01:25 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZtP2R-0002Il-N0 for gllmg-musl@m.gmane.org; Tue, 03 Nov 2015 01:01:23 +0100 Original-Received: (qmail 1924 invoked by uid 550); 3 Nov 2015 00:01:21 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1903 invoked from network); 3 Nov 2015 00:01:21 -0000 Content-Disposition: inline In-Reply-To: <20151102223648.GN8645@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8805 Archived-At: On Mon, Nov 02, 2015 at 05:36:49PM -0500, Rich Felker wrote: > On Sun, Nov 01, 2015 at 02:56:58PM -0500, Rich Felker wrote: > > On Fri, Oct 23, 2015 at 02:30:26PM +0200, Denys Vlasenko wrote: > > > +# > > > +# Put every function and data object into its own section: > > > +# .text.funcname, .data.var, .rodata.const_struct, .bss.zerovar > > > +# > > > +# Previous optimization isn't working too well by itself > > > +# because data objects aren't living in separate sections, > > > +# they are all grouped in one .data and one .bss section per *.o file. > > > +# With -ffunction/data-sections, section sorting eliminates more padding. > > > +# > > > +# Object files in static *.a files will also have their functions > > > +# and data objects each in its own section. > > > +# > > > +# This enables programs statically linked with -Wl,--gc-sections > > > +# to perform "section garbage collection": drop unused code and data > > > +# not on per-*.o-file basis, but on per-function and per-object basis. > > > +# This is a big thing: --gc-sections sometimes eliminates several percent > > > +# of unreachable code and data in final executable. > > > +# > > > +tryflag CFLAGS_AUTO -ffunction-sections > > > +tryflag CFLAGS_AUTO -fdata-sections > > > + > > > +# > > > > This is not just an optimization but going to save us from a horrible > > class of compiler/assembler bugs that threatened to force dropping > > support for all non-bleeding-edge toolchains: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68178 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66609 > > https://sourceware.org/bugzilla/show_bug.cgi?id=18561 > > > > By putting functions/objects in their own sections, the illegal but > > widespread assembler 'optimization' of resolving differences between > > symbols to a constant when one or both of the symbols has a weak > > definition is suppressed, simply because differences of this form are > > never constants when they cross sections. > > > > As such I want to go ahead and apply this regardless of optimization > > issues, but I think we should update the comments and commit message > > to reflect that this is also working around serious toolchain issues. > > I hope to get to it soon now; working on some other things at the > > moment. > > > > BTW thanks a lot for raising the idea of using these options. If it > > hadn't been for your pending patch I probably would never have thought > > of this as a solution to the toolchain problems above. > > Unfortunately there's an issue blocking this patch: some archs' > crt_arch.h asm fragments have code that assumes a "short" branch can > reach _start_c/_dlstart_c. With -ffunction-sections that's not the > case; the entry point and C start code can be moved arbitrarily far > apart by the linker. To fix this we either need to use a fully-general > branch to reach the C code, or have file-specific suppression of > -ffunction-sections for crt1, dlstart, etc. I'd rather just fix the > asm not to make assumptions about shortness -- some of these > assumptions are dangerously close to being wrong at -O0 anyway -- but > to do that I need to audit all the crt_arch.h files, find the affected > ones, and fix them. I'll start taking a look and see how bad it looks. The only affected arch was actually sh, so I just fixed it. So I think it's safe to use these options now. Rich