------- Comment #32 from hubicka at ucw dot cz 2010-04-06 11:05 -------
Subject: Re: [4.5 regression] 0.5% code size
regression caused by r147852
> I think it is a really, really bad signal if a bug like this, where the
> revision that introduced the issue was identified >9 months ago, remains
> unfixed for GCC 4.5.
This particular bug should not affect -Os scores at all as discussed earlier.
Overall unit growth limits will never hit at -Os since we never enlarge unit
size.
I spent fair amount of time tracking down the individual CSiBE code size
increases and fixed most of them. At the moment, I believe, the only remaining
issue is bzip2 size growth. The inlining decisions here are sane at the local
level as inliner sees them, just the resulting binary gets bigger. Inling is a
heuristic even at -Os and we can't expect it to work in all cases. Here the
old inliner got lucky by simply not accounting any stores/loads as real
instructions allowing the functions to be inlined at letting later optimizers
to produce smaller code.
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
