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
