>should not cause any issues (provided compilation goes through). There are few packages which compile fine but break something (I remember some x11-library from bugzilla that broke xorg-server), but generally I agree with you. One annoying package is 64bit firefox, which can easily eat up to 15GB of memory (!!!), at least with gcc 4.8, newer 4.9 branches are said to have fixed this, but since it required complete rework of LTO, new bugs were inevitably introduced.
> OTOH, there are already projects like sqlite which have essentially only one compilation unit, anyway. Thats absolutely correct, there is one sqlite.c file which is split into logical parts for easier code hacking, but it's one file. Interestingly, even sqlite seems to be benefiting from LTO, binary is 5% smaller on my system. On Mon, Apr 28, 2014 at 10:25 AM, Martin Vaeth <mar...@mvath.de> wrote: > C. Bergström <cbergst...@pathscale.com> 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.) > > >
