------- Comment #39 from sherpya at netfarm dot it 2010-04-12 16:55 ------- (In reply to comment #35) > So if I understand correctly, the "state of things" at the moment is this: > > Without LTO: > > Time: 419.938 sec (6 m 59 s) > > with LTO incl linker flags: > > Time: 443.047 sec (7 m 23 s) > > In other words, "with LTO" is ~6% slower than without. > > You say that "results aren't exactly as expected" but I think there is really > not much you can expect. > > First of all, as it is, in GCC 4.5 LTO/WHOPR does not do a whole lot at all. > It > is really only inlining across translation unit boundaries. > > Second, LTO doesn't miraculously increase the number of optimization > opportunities, and very often it makes things worse on register-starved > architectures like i686 (see > http://www.cs.rice.edu/~keith/512/Lectures/30IDFAO.pdf for folklore vs. fact > in > re. interprocedural optimization). > > Third, for C/C++ programs the source code is usually already organized in such > a way to avoid requiring a whole-program view of the program for the compiler > to optimize well. Think .h header files, static inline functions, by-value > call > conventions, etc. And although I don't know clamav very well, I suspect it's > completely I/O bound so optimizing away memory latencies etc. (which is really > what LTO is mostly about) wouldn't help for clamav anyway. > > That doesn't mean that optimizing LTO should slow down your program. It would > be interesting to see if it's somehow possible to identify the part of the > program that got slower. >
6% slower for a new work in progress feature is ok for me, while 60% not :) clamav has a lot of io but also a lot of cpu so it can used for such tests but definitively this patch is usable and could provide more feedbacks to lto -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
