https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87031
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
The recent r15-919-gef27b91b62c3aa left the
/* If the code is going to shrink, we don't need to be extra
cautious on guessing if the unrolling is going to be
profitable.
Move from estimated_unrolled_size to unroll small loops. */
if (unr_insns * 2 / 3
/* If there is IV variable that will become constant, we
save one instruction in the loop prologue we do not
account otherwise. */
<= ninsns + (size.constant_iv != false))
;
case alone but applied the 'cunrolli' flag restriction only to the
param_max_completely_peeled_insns limit applied later:
/* Move 2 / 3 reduction from estimated_unrolled_size, but don't
reduce
unrolled size for innermost loop.
1) It could increase register pressure.
2) Big loop after completely unroll may not be vectorized
by BB vectorizer. */
else if ((cunrolli && !loop->inner
? unr_insns : unr_insns * 2 / 3)
> (unsigned) param_max_completely_peeled_insns)
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "Not unrolling loop %d: "
"number of insns in the unrolled sequence reaches "
"--param max-completely-peeled-insns limit.\n",
loop->num);
return false;
One could either re-use that flag also for the loop-gets-smaller check
for consistency or argue that if loop->inner the 2/3 estimate is likely
off anyway.
Note the check above explicitly considers a loop with an inner loop
to shrink optimistically.
I'm testing what happens if guarding the former condition with cunrolli
for half-consistency.
