https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87031
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-08-22
CC| |hubicka at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Component|target |tree-optimization
Ever confirmed|0 |1
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
size: 24-3, last_iteration: 19-3
Loop size: 24
Estimated size after unrolling: 24
so GCC estimates that unrolling doesn't change size. It arrives here
by applying it's "unrolling saves 1/3 of insns" heuristic.
First of all this isn't controlled by a --param but hard-coded. Second,
it wasn't reduced after we improved estimates of what is optimized away.
Third, we probably shouldn't apply this when optimizing the loop for size
(aka UL_NO_GROWTH).
Honza? Any opinion on the above? Did you ever try removing that * 2/3
completely?
