From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68779 invoked by alias); 26 Nov 2015 02:12:54 -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 68762 invoked by uid 89); 26 Nov 2015 02:12:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_20,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 26 Nov 2015 02:12:52 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 778A0541E1D; Thu, 26 Nov 2015 03:12:49 +0100 (CET) Date: Thu, 26 Nov 2015 06:33:00 -0000 From: Jan Hubicka To: Andi Kleen Cc: Jan Hubicka , gcc-patches@gcc.gnu.org, rguenther@suse.de, hongjiu.lu@intel.com, ccoutant@google.com, iant@google.com Subject: Re: [RFC] Getting LTO incremental linking work Message-ID: <20151126021249.GD5371@kam.mff.cuni.cz> References: <20151125085912.GD58491@kam.mff.cuni.cz> <20151125235858.GI8438@tassilo.jf.intel.com> <20151126003828.GH20593@kam.mff.cuni.cz> <20151126005438.GJ8438@tassilo.jf.intel.com> <20151126015504.GI20593@kam.mff.cuni.cz> <20151126020208.GL8438@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151126020208.GL8438@tassilo.jf.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-11/txt/msg03172.txt.bz2 > > Actually I think it is harder than that, because we need to strip LTO data > > from the object files, so we do not end up with duplicated LTO if the object > > file was already having both LTO and non-LTO stuff in it. > > When I started with LTO I was looking into that, and that is why I originally > implemented slim LTO as a first step. But then I realized that that just adding > the postfixes is much easier, after HJ proposed his linker based solution. > > Anyways can stay with the special binutils for the kernel for now, but it's > a bit of a pain for users to install them (user feedback is generally that > this is the hardest part) > > I'm a bit surprised that the programs you test (Firefox, LibreOffice etc.) > don't have .S files. They don't do incermental linking. They build static libraries that works just fine. Indeed it would be nice to have things working in general. > > > > > I am not sure we can/want to implement this w/o some sort of support from > > plugin side. It would basically mean doing another incremnetal linker in the > > plugin. > > > > How does HJ's binutils work for fat LTO? > > I believe it works too (pretty sure I tested it at some point) > > Here's the original design spec > > https://sourceware.org/ml/binutils/2011-04/msg00404.html > Yep, i saw this a while ago, but forgot how to find it. Thanks! Now I remember that HJ's binutils has IR objects (which are slim or fat LTO) and mixed objects which are essentially two objects together. I suppose the IR linking I impleemnted should work just fine with HJ's approach and we could make lto-plugin to skip the path switching to early codegen. Over the current HJ's implementation the advantage is that you will get faster WPA at kernel link time. It would be nice to arrive with a solution for mainline bintutils. Honza