https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aldyh at gcc dot gnu.org
--- Comment #21 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Assuming that changing the condition of the loop to !=, would fix the
regression, could we use range info to determine this?
For instance, right before the ivopts pass, we have:
<bb 2> [15.00%]:
# RANGE [0, 65535] NONZERO 65535
_19 = (int) c_11(D);
if (_19 > 0)
goto <bb 3>; [85.00%]
else
goto <bb 7>; [15.00%]
<bb 3> [12.75%]:
<bb 4> [85.00%]:
# p_20 = PHI <p_14(6), p_10(D)(3)>
# i_21 = PHI <i_15(6), 0(3)>
# x_22 = PHI <x_13(6), 0(3)>
_1 = *p_20;
x_13 = _1 + x_22;
p_14 = p_20 + 4;
# RANGE [0, 65535]
i.1_2 = (unsigned short) i_21;
# RANGE [0, 65535]
_3 = i.1_2 + 1;
i_15 = (short int) _3;
# RANGE [-32768, 32767]
_4 = (int) i_15;
if (_4 < _19)
goto <bb 6>; [85.00%]
else
goto <bb 5>; [15.00%]
The range for the max value `c' (_19) is [0..65535]. So if we know that the
induction variable `i' (_4) starts at the lower end of that (0), and we
increment the IV by 1, then we could always replace the < by a !=, right? This
would avoid having to do loop versioning.
If this is acceptable, would we do this in the ivopts pass? If so, I guess we
could start by explaining to the pass that _4 is an IV. Because right now I
see that we determine that everything but _4 is an IV: i_21, i.1_2, _3, i_15.
Thoughts/hints greatly appreciated :).
