GCC 10 LTO documentation

Jonathan Wakely jwakely.gcc@gmail.com
Tue Jun 22 17:02:27 GMT 2021


On Tue, 22 Jun 2021 at 17:08, Xi Ruoyao <xry111@mengyan1223.wang> wrote:
>
> On Tue, 2021-06-22 at 16:52 +0100, Jonathan Wakely wrote:
> > On Tue, 22 Jun 2021 at 16:14, Xi Ruoyao <xry111@mengyan1223.wang>
> > 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.
>
> I think he means:
>
> cc main.c lib1.a lib2.a lib3.a lib4.a
>
> lib[1-4].a are all built with -flto.  In this case, unfortunately gcc
> will still run a whole LTO pass for all object files in lib[1-4].a.  But
> Chris wants 4 LTO passes, each for one static library and abandon the
> optimization oppertunity crossing library files.

Yes, but depending on the form of the libraries APIs, there may not
*be* much opportunity for optimizing across them, and so the final
link wouldn't spend much time trying to do it. Maybe.


More information about the Gcc-help mailing list