------- Comment #15 from hubicka at gcc dot gnu dot org 2010-03-07 20:37 ------- I've been discussing this on IRC a while ago with Richard Guenther, but forgot to add a record.
It seems that for 4.5, it is best to leave inlining heruistics as it is. THe code size regression come mainly from bzip that is excercising kind of typical "bad luck" scenario. Other known problem in 4.5 inlining is tramp3d where we now deliver worse than best known performance, but still not worse than one of 4.4. I spent some time playing with this and only way to get 4.5 inliner to solve these faults is to add new parameter that allows early inlining to inline forwarder functions that do increase code size estimates by small amount. This helps to solve both tramp3d and bzip problems but also cause code size issues in some benchmarks (mostly not regressions over 4.4) and is quite ugly. Since re-tunning heuristics needs significant amount of effort and it was done earlier in stage1 of 4.5 after merging changes from pretty-ipa, it seems better to leave as it is now. Also after LTO merge it seems, according to results posted by Vladimir Marakov, that the inliner is actually perfomring very well compared to other compilers. For 4.6 I do have number of plans. With FRE in early optimization queue we invalidate need for some of early inlining and also IPA stuff should be making us less dependent on inling overall. But I would propose this PR to be wontfix for 4.5. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
