From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121497 invoked by alias); 24 Jul 2019 06:47:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 121489 invoked by uid 89); 24 Jul 2019 06:47:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=meta, HX-Languages-Length:2320 X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Jul 2019 06:47:16 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 5ED60AEE9; Wed, 24 Jul 2019 06:47:14 +0000 (UTC) Subject: Re: [PATCH] Come up with -flto=auto option. To: Jeff Law , Michael Matz Cc: Jan Hubicka , gcc-patches@gcc.gnu.org, Richard Biener References: <95f20c0a-81a3-2319-326b-3c5baf71e2d1@suse.cz> <20190723092040.czs64os2qymax7sq@kam.mff.cuni.cz> <7b383b21-89ad-52ed-1fb1-e44723e8be86@redhat.com> <6b71acd8-27ba-a539-4ae4-7853cd9a672e@redhat.com> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: Date: Wed, 24 Jul 2019 06:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg01550.txt.bz2 On 7/24/19 12:32 AM, Jeff Law wrote: > On 7/23/19 8:23 AM, Martin Liška wrote: >> On 7/23/19 3:57 PM, Jeff Law wrote: >>> On 7/23/19 7:50 AM, Michael Matz wrote: >>>> Hi, >>>> >>>> On Tue, 23 Jul 2019, Jeff Law wrote: >>>> >>>>>> great you found time to make this. It should become the default for >>>>>> -flto IMO. >>>>> I was going to hack it into the rpm configury bits since we have access >>>>> to the # cores there. But an auto-selector within GCC is even better. >>>>> >>>>> BTW, isn't this all going to wreck havoc with reproducible builds since >>>>> partitioning can affect code generation? That's one of our open >>>>> questions... >>>> >>>> See Richi for this, but the reason for -flto=auto (or just -flto, or >>>> whatever the endresult will be) is _also_ reproducible builds, because >>>> some packages like to encode the compile flags into their binaries and >>>> hence would change depending on build host just because of "-flto=32" vs. >>>> "-flto=64" even when the code remains exactly the same. >>> Makes sense. >>> >>> What did you end up doing with old autoconf scripts that aren't LTO >>> safe? Many of the older style tests to see if a function exists are >>> broken by LTO. I've seen more issues with this than anything in the LTO >>> space so far. >> >> Well, I've seen some of these failures, but only a few. > Many appear to be silent, possibly not really affecting anything (like > all the packages that test for doprnt, but really don't care about it in > the end). But there were enough real failures that I put in auditing > to detect any cases where we get different config.h files with LTO vs > non-LTO and that is tripping often enough to have my concerns about how > much work it's going to be to get everything fixed. I see. > > > But still, overall we're moving forward. Next step is to get everything > classified into buckets and start iterating. Presumably you'd be open > to a google doc of some kind where we can coordinate any such efforts? Sure, I'm open. In the meantime, I've got a META issue that I use for tracking of LTO-related issues in openSUSE: https://bugzilla.opensuse.org/show_bug.cgi?id=1133084 Martin > > jeff > > ps. I'm on PTO July 25 to Aug 5, so not much is going to happen in the > next couple weeks :-) >