From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25547 invoked by alias); 12 Mar 2018 15:05:06 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 25531 invoked by uid 89); 12 Mar 2018 15:05:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=UD:mozilla.org, Ritter, ritter, click X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Mar 2018 15:04:59 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id A250E543BDD; Mon, 12 Mar 2018 16:04:56 +0100 (CET) Date: Mon, 12 Mar 2018 15:05:00 -0000 From: Jan Hubicka To: Martin =?iso-8859-2?Q?Li=B9ka?= Cc: GCC Development , Richard Biener , Michael Matz , tom@mozilla.com Subject: Re: How big (and fast) is going to be GCC 8? Message-ID: <20180312150456.GA81162@kam.mff.cuni.cz> References: <5ec1f1c1-e0f6-5681-b6c6-cf8b076bc02a@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ec1f1c1-e0f6-5681-b6c6-cf8b076bc02a@suse.cz> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2018-03/txt/msg00142.txt.bz2 Hello, I have also re-done most of my firefox testing similar to ones I published at http://hubicka.blogspot.cz/2014/04/linktime-optimization-in-gcc-2-firefox.html (thanks to Martin Liska who got LTO builds to work again) I am attaching statistics on binary sizes. Interesting is that for firefox LTO is quite good size optimization (16% on text) and similarly FDO reduces text size and combines well with LTO, which is bit different from Martin's gcc stats. I have looked into this very briefly and one isse seems to be with the way we determine hot/cold threshold. binary size text relocations data EH rest gcc6 -O3 90448658 12887358 13720073 13035704 257839 gcc6 -O3 -flto 75810786 12145211 12390185 8422776 240002 gcc6 -O3 + FDO 67087824 13008294 13655305 13719944 259585 gcc6 -O3 -flto + FDO 60206898 12169803 12334113 9083088 240050 gcc7 -O3 93233440 12928831 13780313 13578224 257408 gcc7 -O3 -flto 76764274 12128031 12405369 8420448 240662 gcc7 -O3 + FDO 67500688 12994279 13650185 13661760 263400 gcc7 -O3 -flto + FDO 59776994 12151360 12325217 8971344 239501 gcc8 -O2 80311120 12939568 13763033 12948752 258711 gcc8 -O2 -flto 69156752 12109236 12475801 8501152 240163 gcc8 -O3 89913648 12924468 13790393 13374328 256867 gcc8 -O3 -flto 75971122 12138528 12426649 8593024 239861 gcc8 -O3 + FDO 67047632 12996890 13707017 13146232 263413 gcc8 -O3 -flto + FDO 58951410 12146008 12377161 8634152 241765 I also did some builds with clang. Observation is that clang's -O3 binary is smaller than ours, while our LTO/FDO builds are smaller than clang's (LTO+FDO build quite substantially). Our EH is bigger than clang's which is probably something to look into. One problem I am aware of is that our nothrow pass is not type sensitive and thus won't figure out if program throws an exception of specific type and catches it later. clang6 -O3 84754848 13032018 13597433 10791528 371429 clang6 -O3 -flto 90757024 12273574 12258521 6841424 350585 clang6 -O3 -flto=thin 92940576 12376724 12479233 7974856 353171 clang6 -O3 + FDO 81776880 13136428 13574489 11501344 385123 clang6 -O3 -flto=thin+FDO 88374432 12405075 12434297 9574416 356508 clang6 -O3 -flto + FDO 90637168 12288433 12244265 9023304 349078 I also did some benchmarking and found at least an issue with -flto -O3 hitting --param inline-unit-growth bit too early so we do not get much benefits (while clang does but it also does not reduce binary size). -O3 -flto + FDO or -O2 -flto seems to work well. Will summarize the results later. Firefox developer Tom Ritter has tested LTO with FDO and without here (it is rather nice interface - I like that one can click to the graph and see the results in context of other tests done recently). This is done with gcc6. Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?format=default&id=521435 non-FDO build: https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-central&newProject=try&newRevision=12ce14a5bcac9975b41a1f901bfc3a8dcb2d791b&framework=1&showOnlyImportant=1&selectedTimeRange=172800 FDO build: https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-central&newProject=try&newRevision=7e5bd52e36fcc1703ced01fe87e831a716677295&framework=1&showOnlyImportant=1&selectedTimeRange=172800 Honza