https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107176
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> final value replacement:
> b_lsm.8_26 = PHI <b_lsm.8_15(4)>
> with expr: 1
> final stmt:
> b_lsm.8_26 = 1;
>
> where
>
> (get_scalar_evolution
> (scalar = b_lsm.8_15)
> (scalar_evolution = {0, +, 1}_1))
> (chrec_apply
> (varying_loop = 1)
> (chrec = {0, +, 1}_1)
> (x = 1)
> (res = 1))
>
> and
>
> <bb 3> [local count: 955630225]:
> _1 = (unsigned int) b_lsm.8_15;
> _2 = _1 + 4294967206;
> # RANGE [irange] long int [0, 4294967295] NONZERO 0xffffffff
> _12 = (long int) _2;
> # RANGE [irange] long int [91, 4294967386] NONZERO 0x1ffffffff
> _3 = _12 + 91;
>
> <bb 4> [local count: 1073741824]:
> # b_lsm.8_15 = PHI <0(2), _3(3)>
For comparison in PR66375 we have
<bb 4> :
# c_6 = PHI <0(2), c_12(3)>
a.1_5 = a;
if (a.1_5 <= 12)
goto <bb 3>; [INV]
else
goto <bb 5>; [INV]
<bb 3> :
_1 = (signed char) c_6;
_2 = (int) _1;
c_12 = _2 + -11;
_4 = a.1_5 + 1;
a = _4;
goto <bb 4>;
so the backedge definition is
(long)((unsigned)IV + -90u) + 91
vs.
(int)(signed char)IV + -11
I think the issue is the CONVERT_EXPR handling in follow_ssa_edge_expr where
it isn't all that clear in which case we can analyze the evolution in the
narrower or the wider type. In the case in this PR we mishandled the
middle conversion while in the older case we mishandle the "initial"
conversion. I suspect that trying to optimize things on-the-fly is
difficult (and reasoning about the relevant cases there).
I've tried (again) to more correctly have the current evolution tentative
until we hit the loop PHI again when following the use-def chain from the
latch definition, but then we don't even know whether we will have an
evolution in the end (tried { initial, +, scev_not_known }). Going fully
symbolic will lead to the issue pointed out in comment 6 of PR66375,
we'd get { (int)(signed char)0, +, -11 } which isn't what we want.
If, as in this bug, we have two evolutions in different types, we probably
have to give up. Maybe we need to think of a PLUS as { unknown, +, val }
and instead fend off "wrongly" typed evolutions when we reach the
loop PHI node again. But then the PR66375 case _does_ have an expression
correctly describing the evolution of the IV. Just in this PRs case there
is none I think. Or rather, I guess it would be
{ (long){ 0u, +, -90u }_1, +, 90 }_1 but that wouldn't be affine at least.
