Compilation performance with LTO slim objects and non-LTO linking

R. Diez via gcc-help gcc-help@gcc.gnu.org
Tue Nov 20 09:53:00 GMT 2018


Hi all:

My question is whether linking with LTO disabled, but using LTO-compiled 
slim objects as input files, will make the linker compile all modules 
(GIMPLE bytecode->assembly) every time, and therefore dramatically slow 
down link (and overall build) time.

The details to this question are:

I regularly rebuild a huge number of makefile targets for many different 
small devices (overnight/continuous integration build), so compilation 
performance is important for me. To that effect, I have built a 
GCC-based embedded toolchain with Newlib. Everything is statically built.

Some of the devices are so small that even debug builds (with assertions 
enabled) need to use LTO. Debug builds for larger targets do not need 
LTO. Many devices share a few common static libraries.

I would like to understand the implications of LTO with regards to 
compiler performance.

In order to maximize LTO gains, I should build the Newlib inside the 
toolchain with LTO too. The common libraries should also be built with LTO.

Depending on each device size, its debug build may need LTO (slow 
build), or not (fast build).

If Newlib and the common libraries were built with LTO, I have 2 choices:

1) Generate slim objects with -fno-fat-lto-objects (the default).
2) Generate fat objects with -ffat-lto-objects.

I believe it is allowed to mix LTO and non-LTO objects when linking with 
and without LTO. Or is this wrong anyway?

Say a particular target is linked without LTO. If I am  using slim 
objects, the linker will have to compile all objects (GIMPLE 
bytecode->assembly) every time. Should I expect a big performance hit 
when compiling? In this case, it would be worth to build Newlib and all 
common libraries with fat objects.

I could not find in the documentation any mention about compilation 
performance with slim objects and non-LTO linking.

Many thanks in advance,
   rdiez



More information about the Gcc-help mailing list