------- Comment #6 from hubicka at ucw dot cz 2009-11-30 09:59 ------- Subject: Re: missed optimization leads to several times slower code
> Digression: this suggests an attribute such as "inline_if_reduces" which > inlines if the inlined (callee) code is simplified, but otherwise keeps it out > of line. In other words, code growth is okay, but not when the savings is > only > call/return reduction. For "switch_case()", "inline_if_reduces_50" (inline if > the inlined callee is under 50% of the out-of-line version) would be good: > here, inlining reduces the dynamic code path by about 80% and the inlined code > size (at each caller) is under 5% of the size before inline simplification. Implementing this is not really doable: the compiler never know how much the function will simplify before it actually inlines the function (and other functions called by the function inlined into) and optimizes, since the effectivity of optimizations really depends on the whole function body after inlining. This is of course main problem of inliner heuristics - it is one of most important heuristics in compiler but it is also one operating on very few information. We have little estimates of simplifications already in 4.5 and will have more in next release, but doing 100% correct decisions here is not possible. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42209
