From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114215 invoked by alias); 26 Nov 2015 02:02:12 -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 114108 invoked by uid 89); 26 Nov 2015 02:02:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mga02.intel.com Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Nov 2015 02:02:10 +0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP; 25 Nov 2015 18:02:08 -0800 X-ExtLoop1: 1 Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.156]) by fmsmga001.fm.intel.com with ESMTP; 25 Nov 2015 18:02:08 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id 7EDA9302AFE; Wed, 25 Nov 2015 18:02:08 -0800 (PST) Date: Thu, 26 Nov 2015 02:12:00 -0000 From: Andi Kleen To: Jan Hubicka Cc: 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: <20151126020208.GL8438@tassilo.jf.intel.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151126015504.GI20593@kam.mff.cuni.cz> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2015-11/txt/msg03171.txt.bz2 On Thu, Nov 26, 2015 at 02:55:04AM +0100, Jan Hubicka wrote: > > > > > I suppose we could play a games here with slim LTO: claim the file, see if > > > there are any symbols defined in the non-LTO symbol table and if so, interpret > > > read the symbol table and tell linker about the symbols and at the very end > > > include the offending object file in the list of objects returned back to > > > linker. > > > > > > The linker then should take the symbols it wants. There would be some fun > > > involved, because the resolution info we get will consider the symbols > > > defined in that object file to be IR which would need to be compensated for. > > > > Yes something like that would be needed. > > 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. > > 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 -Andi -- ak@linux.intel.com -- Speaking for myself only