C. Bergström <[email protected]> wrote: > Can you name a single package that you use which receives a measurable > benefit from LTO? (Just asking)
Like for every optimization flag, it is easy to construct particular examples: It can help a lot if e.g. a user's string-helper library is inlined. Concerning memory, it can help a lot if duplicate data (e.g. macros containing paths) from different compilation units can be merged. I guess (though I did no benchmarks) this is why eix profits so much from LTO: it was already mentioned that eix's size is *considerably* smaller with LTO. Surprisingly, eix does almost not profit from clang's LTO. I guess it is not the different implementation of LTO but of the remaining optimizers which make the difference here. Again: These are just guesses, I never tried to analyze. I use it globally, because LTO *can* help a lot and should never hurt performance if the remaining optimizers are good and should not cause any issues (provided compilation goes through). The price is clear: More than doubled compilation time (which takes place in the linking phase and thus cannot be ccache'd) and for some packages insane memory requirements which forbid its usage on some systems. > IPA (aka whole program and LTO) is by far the hardest optimizations > I've ever personally had to debug/engineer/tune in a compiler. > Making it robust [... I guess it is not a problem by itself: It just triggers cases which "in practice" do not occur otherwise, since most developer's will typically write relatively small compilation units. So you just now you see the bugs hidden in the algorithms which before never were found... OTOH, there are already projects like sqlite which have essentially only one compilation unit, anyway. (I am guessing this only from the output shown during compilation, so I might be wrong.)
