https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100934
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at gcc dot gnu.org
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Somehow niter analysis computes two iterations for the loop but that doesn't
look correct. That might be the result of extra simplification triggered by
the change but it most definitely looks like a latent issue to me
<bb 2> [local count: 119883187]:
d.3_2 = d;
a.1_1 = a;
iftmp.0_17 = a.1_1 % 2;
goto <bb 4>; [100.00%]
<bb 12> [local count: 0]:
<bb 3> [local count: 59073784]:
# h_29 = PHI <0(7), h_21(12)>
# f_26 = PHI <_30(7), f_31(12)>
<bb 4> [local count: 239802342]:
# iftmp.0_10 = PHI <iftmp.0_17(3), 0(2)>
# h_28 = PHI <h_29(3), 0(2)>
# f_31 = PHI <f_26(3), 0(2)>
h_21 = h_28 + 1;
_30 = f_31 + 1;
if (h_21 != 2)
goto <bb 12>; [0.00%]
else
goto <bb 7>; [100.00%]
<bb 7> [local count: 239802342]:
if (_30 != 2)
goto <bb 3>; [50.01%]
else
goto <bb 8>; [49.99%]
<bb 8> [local count: 119883187]:
# iftmp.0_20 = PHI <iftmp.0_10(7)>
c = d.3_2;
b = iftmp.0_20;
e = iftmp.0_20;
return 0;
}
niter is chrec_don't_know but we have a set nb_iterations_upper_bound which
likely survives incorrectly from some CFG merging. In fact loops are
removed at
a-t.c.109t.thread1:fix_loop_structure: removing loop 3
a-t.c.123t.thread2:fix_loop_structure: removing loop 2
a-t.c.152t.cddce2:fix_loop_structure: removing loop 4
loop 1 gets its nb_iterations_upper_bound in EVRP but when loop 2 is
removed it is not reset appropriately. In fact thread2 creates quite some
mess which includes turning loop2 into some irreducible region.
There's some scattered resetting of the upper bound (estimates) but no
API for this (and free_numbers_of_iterations_estimates doesn't do it).
loop_father->any_upper_bound = false;
loop_father->any_likely_upper_bound = false;
in fact we only have
gimple-loop-interchange.cc: iloop.m_loop->any_upper_bound = false;
gimple-loop-interchange.cc: oloop.m_loop->any_upper_bound = false;
tree-cfgcleanup.c: dest->loop_father->any_upper_bound = false;
tree-vectorizer.c: loop->any_upper_bound = false;
I think the backwards threader has to get some guards - whenever we thread
through a loop latch edge we have to reset niter estimates/bounds. But I'm
not at all familiar with said code. Jeff - do you know a single place to
tackle this?
