From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33953 invoked by alias); 26 Nov 2015 01:55:10 -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 33819 invoked by uid 89); 26 Nov 2015 01:55:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,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 01:55:08 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 12DDD542B33; Thu, 26 Nov 2015 02:55:04 +0100 (CET) Date: Thu, 26 Nov 2015 02:02: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: <20151126015504.GI20593@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151126005438.GJ8438@tassilo.jf.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-11/txt/msg03170.txt.bz2 > > > In theory we could change the build system to avoid that case though, but > > > it would need some changes. > > > > > > It would be better if that could be handled somehow. > > > > How does this work with your patchset? Ideally we should have way to claim > > only portions of object files, but we don't have that. If we claim the file, > > the symbols in real symbol table are not visible. > > It works with HJ's Linux binutils. It handles LTO and non LTO separately. > > > 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. 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? Honza