On Tue, 22 Jun 2021 at 16:14, Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx> wrote: > > On Tue, 2021-06-22 at 14:02 +0100, Jonathan Wakely via Gcc-help wrote: > > On Mon, 21 Jun 2021 at 14:42, Chris S wrote: > > > Is it possible to build static libraries that have LTO optimizations > > > applied to the object code they contain (that is, all the code in > > > that > > > library is optimized together with LTO), but when built together > > > into a > > > final binary, no additional LTO is performed? We have several > > > large, > > > static libraries that are mostly unrelated, and are looking for ways > > > to > > > reduce a massive increase in build times after moving to g++10, > > > where > > > almost 80% of the time is spent in LTO. Having optimized individual > > > libraries but not a global optimized binary might be a reasonable > > > tradeoff. Is this possible? > > I tried "gcc -Wl,--whole-archive lib.a -Wl,-r -nostdlib -flinker- > output=nolto-rel -o lib.o", which seems working for a very simple > testcase. But I'm not sure if it's really correct. > > > A static library is just an archive file containing object files. No > > LTO is done "between" those files, they're just added to the archive. > > That's because creating a static library is not "linking". > > > > If you do not use -flto when doing the final link, you might as well > > not use -flto when compiling the objects that go into your static > > library, because otherwise you're adding all the extra LTO information > > to the objects and then ignoring it when linking. > > It's not "extra" information. Object files created with -flto only > contains GIMPLE which can only be linked with LTO enabled, the "normal" > object code is not there. For example, if lib.a contains several object > files compiled with -flto: > > cc main.c lib.a -flto # main.c is compiled with LTO, and LTO will > # run for main.o and object files in lib.a > > cc main.c lib.a # main.c is not compiled with LTO, but LTO > # will still run for object files in lib.a > > cc main.c lib.a -fno-lto # error, linker will say > # "plugin needed to handle lto object" > > (Unless -ffat-lto-objects is used.) Thanks for the correction. So then maybe that's what Chris wants: the objects in the static libs can be LTO'd but the objects in the main executable won't be. And if it's still too slow, only enable LTO for some static libs, where it gives significant performance gain.
