https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68911
--- Comment #5 from amker at gcc dot gnu.org ---
For the case concerned:
<bb 8>:
e_15 = e_1 + 1;
<bb 13>:
# e_1 = PHI <e_2(3), e_15(8), e_12(7)>
if (e_1 <= 93)
goto <bb 8>;
else
goto <bb 10>;
Loop niter gives:
Analyzing # of iterations of loop 2
exit condition [e_8, + , 1] <= 93
bounds on difference of bases: -4294967202 ... 93
result:
zero if e_8 > 94
# of iterations 94 - e_8, bounded by 94
It also records induction variable {e_8, 1} as non-overflow control iv. Thus
below checks in adjust_range_with_scev returns false and value range is updated
with [min, VRP[e_8].max + bound].
dir = scev_direction (chrec);
if (/* Do not adjust ranges if we do not know whether the iv increases
or decreases, ... */
dir == EV_DIR_UNKNOWN
/* ... or if it may wrap. */
|| scev_probably_wraps_p (init, step, stmt, get_chrec_loop (chrec),
true))
return;
Unfortunately, it's possible that the loop exits immediately. When that is the
case, computing VRP[e_8].max + bound would result in overflow.
So maybe we need to check if the loop exits immediately before call to
scev_probably_wraps_p. This should not result any regression since there is no
useful range update anyway if the loop exits immediately.
Also following code in adjust_range_with_scev could be improved to handled
overflow cases. For this given case, we can generate ANTI-range info like
![VRP[e_8].max + bound, VRP[e_8].min].
