On Tue, Aug 2, 2022 at 1:41 PM Aldy Hernandez <al...@redhat.com> wrote:
>
> On Tue, Aug 2, 2022 at 9:19 AM Richard Biener
> <richard.guent...@gmail.com> wrote:
> >
> > On Mon, Aug 1, 2022 at 8:17 AM Aldy Hernandez via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> > >
> > > Even though ranger is type agnostic, SCEV seems to only work with
> > > integers. This patch removes some FIXME notes making it explicit that
> > > bounds_of_var_in_loop only works with iranges.
> >
> > SCEV also handles floats, where do you see this failing? Yes, support is
> > somewhat limited, but still.
>
> Oh, it does? We could convert range_of_ssa_name_with_loop_info to
> the type agnostic vrange if so... (see attached untested patch).
>
> I'm looking at the testcase for 24021 with the attached patch, and
> bounds_of_var_in_loop() is returning false because SCEV couldn't
> figure out the direction of the loop:
>
> 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 (NULL_TREE, init, step, stmt,
> get_chrec_loop (chrec), true))
> return false;
>
> The chrec in question is rather simple... a loop increasing by 0.01:
>
> (gdb) p debug(chrec)
> {1.00000000000000002081668171172168513294309377670288085938e-2, +,
> 1.00000001490116119384765625e-1}_1
Well, yeah - I meant it "supports" floats in that it can analyze the CHRECs (you
quote that) and it shouldn't ICE anywhere. But of course some things may
return "I don't know" when not implemented. Like scev_direction which has
step = CHREC_RIGHT (chrec);
if (TREE_CODE (step) != INTEGER_CST)
return EV_DIR_UNKNOWN;
if (tree_int_cst_sign_bit (step))
return EV_DIR_DECREASES;
else
return EV_DIR_GROWS;
so it lacks support for REAL_CST step. Would be interesting to see what happens
with a loop with -0.0 "increment" and honoring signed zeros. That said,
inspecting the sign bit of a REAL_CST and handling zero (of any sign) as
EV_DIR_UNKNOWN would probably work.
> I also see that bounds_of_var_in_loop() calls niter's
> max_loop_iterations(), which if I understand things correctly, bails
> at several points if the step is not integral.
Yes, a lot of code is "simplified" by not considering FP IVs. But it "works"
in terms of "it doesn't ICE" ;)
> I'd be happy to adapt our code, if SCEV can give me useful information.
>
> Aldy
