[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

["hubicka at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- 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