https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233
--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Aldy Hernandez from comment #10)
> (In reply to Jakub Jelinek from comment #8)
>
> > And on the ranger side why we have determined the [0, 5] range rather than
> > [0, 4], whether it is related to inaccurate number of iterations estimation,
> > or ranger using it incorrectly, ...
>
> The [0, 5] is actually coming from SCEV, which ranger is using to refine the
> range. Presumably, ranger is doing worse than SCEV, because it doesn't
> improve it.
>
> $ grep 'Loops range fo' a.c.*evrp
> Loops range found for i_3: [irange] int [0, 5] NONZERO 0x7 and calculated
> range :[irange] int [-2147483647, +INF]
> Loops range found for i_3: [irange] int [0, 5] NONZERO 0x7 and calculated
> range :[irange] int [0, 6] NONZERO 0x7
>
> Perhaps Andrew can pontificate on the recalculations / iterations / etc.
Im not sure what to add.
SCEV tells us its [0,5] .
Statement MEM <struct T> [(struct S *)t_9(D)].f[i_3].y = 1;
is executed at most 4 (bounded by 4) + 1 times in loop 1.
Induction variable (int) 0 + 1 * iteration does not wrap in statement MEM
<struct T> [(struct S *)t_9(D)].f[i_3].z = 2;
in loop 1.
Statement MEM <struct T> [(struct S *)t_9(D)].f[i_3].z = 2;
is executed at most 4 (bounded by 4) + 1 times in loop 1.
Induction variable (int) 0 + 1 * iteration does not wrap in statement MEM
<struct T> [(struct S *)t_9(D)].f[i_3].x = 3;
in loop 1.
Statement MEM <struct T> [(struct S *)t_9(D)].f[i_3].x = 3;
is executed at most 4 (bounded by 4) + 1 times in loop 1.
Induction variable (int) 0 + 1 * iteration does not wrap in statement MEM
<struct T> [(struct S *)t_9(D)].f[i_3].z = 2;
in loop 1.
Statement MEM <struct T> [(struct S *)t_9(D)].f[i_3].z = 2;
is executed at most 4 (bounded by 4) + 1 times in loop 1.
Trying to walk loop body to reduce the bound.
Found better loop bound 5
I see nothing else in the IL to help ranger make any other decision, so it
defers to SCEV, and the transformtion to rewrite the array index to [5] seems
spot on, its the only possible value that can be there... THe branch condition
is:
_1 = t_9(D)->h;
i.0_2 = (unsigned int) i_3;
if (_1 > i.0_2)
goto <bb 3>;
Ranger knows nothing of the value of _1, and with i_3 being [0,5] there is
nothing that I can see that ranger could do
Why does scev decide 5 is a better bound?
