From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129457 invoked by alias); 7 Feb 2018 08:40:57 -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 129328 invoked by uid 89); 7 Feb 2018 08:40:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=H*i:sk:a976c31, H*f:sk:a976c31, quality X-HELO: mailrelay3-3.pub.mailoutpod1-cph3.one.com Received: from mailrelay3-3.pub.mailoutpod1-cph3.one.com (HELO mailrelay3-3.pub.mailoutpod1-cph3.one.com) (46.30.212.12) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 08:40:46 +0000 X-HalOne-Cookie: c787bf8b130c4cfea14051e7c10d089663718fc9 X-HalOne-ID: 94fe6a08-0be2-11e8-bf1e-d0431ea8bb03 Received: from twilight.localnet (unknown [46.94.154.216]) by mailrelay3.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 94fe6a08-0be2-11e8-bf1e-d0431ea8bb03; Wed, 07 Feb 2018 08:40:42 +0000 (UTC) From: Allan Sandfeld Jensen To: gcc@gcc.gnu.org Cc: Jan Hubicka , Richard Biener , jh@suse.cz Subject: Re: Resolving LTO symbols for static library boundary Date: Wed, 07 Feb 2018 08:40:00 -0000 Message-ID: <3735809.TNEBcfqz21@twilight> In-Reply-To: References: <38925973.88kXsFSiyi@twilight> <68CCCBEA-05E1-4C80-B06C-9068FD1DD912@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00061.txt.bz2 On Dienstag, 6. Februar 2018 01:01:29 CET Jan Hubicka wrote: > Dne 2018-02-05 18:44, Richard Biener napsal: > > On February 5, 2018 12:26:58 PM GMT+01:00, Allan Sandfeld Jensen > > > > wrote: > >> Hello GCC > >> > >> In trying to make it possible to use LTO for distro-builds of Qt, I > >> have again > >> hit the problem of static libraries. In Qt in general we for LTO rely > >> on a > >> library boundary, where LTO gets resolved when generating the library > >> but no > >> LTO-symbols are exported in the shared library. This ensure the > >> library > >> has a > >> well defined binary compatible interface and gets LTO optimizations > >> within > >> each library. For some private libraries we use static libraries > >> however, > >> because we don't need binary compatibility, but though we don't need > >> BC > >> > >> between Qt versions, the libraries should still be linkable with > >> different gcc > >> versions (and with different compilers). However when LTO is enabled > >> the > >> static libraries will contain definitions that depend on a single gcc > >> version > >> making it unsuitable for distribution. > >> > >> One solution is to enable fat-lto object files for static libraries > >> but > >> that > >> is both a waste of space and compile time, and disables any LTO > >> optimization > >> within the library. Ideally I would like to have the static library do > >> LTO > >> optimizations internally just like a shared library, but then exported > >> as > >> static library. > >> > >> I suspect this is more of gcc task than ar/ld task, as it basically > >> boils down > >> to gcc doing for a static library what it does for shared library, but > >> maybe > >> export the result as a single combined .o file, that can then be ar'ed > >> into a > >> compatible static library. > >> > >> Is this possible? > > > > Hmm. I think you could partially link the static archive contents into > > a single relocatable object. Or we could add a mode where you do a > > 1to1 LTO link of the objects and stop at the ltrans object files. You > > could stuff those into an archive again. > > > > I'm not sure how far Honza got partial LTO linking to work? > > Parital linking of lto .o files into single non-lto .o file should work > and it will get you cross-module optimization done. The problem is that > without resolution info compiler needs to assume that all symbols > exported by object files are possibly referneced by the later > incremental link and thus the code quality will definitly not be > comparable with what you get for LTO on final binary or DSO. Still > should be better than non-lto build. > I would be curious if it is useful for you in practice. > How would I do that partial link, and what are the requirements? Best regards 'Allan