--- Comment #7 from rguenth at gcc dot gnu dot org 2009-11-30 10:26 ---
THus fixed in 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- 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
--- Comment #5 from gb-0001 at xsim dot com 2009-11-30 02:14 ---
>[It works in 4.5 with "inline", "always_inline" not needed.]
Ah, I misunderstood -- seems good to me. I'd say fixed in 4.5 unless somebody
else cares.
Digression: this suggests an attribute such as "inline_if_reduces" w
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-30 01:15 ---
I have seen this also with code like switch_case.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-29 18:21 ---
With 4.5 it works when the function is declared inline (not always_inline).
It's not possible to annotate call-sites with inline information.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42209
--- Comment #2 from gb-0001 at xsim dot com 2009-11-29 17:34 ---
>[For the call in the loop GCC assumes it is more beneficial]
And in this case it is: the inner loop code is yet simpler than the
prologue/eiplogue code.
>[If you are sure it is always beneficial...]
It is not always ben
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 12:54 ---
GCC has to weight code-size and compile-time increase against performance
improvements when deciding on inlining functions. For the call in the loop
GCC assumes it is more beneficial to do the inlining compared to t
