GCC 10 LTO documentation

[Chris S]

Thank you.  As a follow up, without turning it off completely, is there any
way to limit the scope of LTO such that when it brings those static
libraries together, they are not fully mixed?  That is, building the
executable could do less work by only considering certain groups of files
instead of trying to "LTO All The Things".   After upgrading from g++7 to
g++10, after compiling, the LTO time for one application went from 20
minutes to 70 minutes with no change in code, and we're looking for ideas
and ways to reduce this (while maintaining a statically linked
executable).  In our case, each static library can be thought of as a
closely knit set of files that does not need full LTO with all the other
code from the other libraries.

Thanks,
Chris

On Tue, Jun 22, 2021 at 8:02 AM Jonathan Wakely <jwakely.gcc@gmail.com>
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?
>
> 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.
>
> If you use dynamic libraries, they can be LTO-optimized internally,
> and you get partial benefits of LTO even if you don't use LTO when
> linking the final binary.
>