On Tue, Aug 2, 2022 at 2:07 PM Richard Biener
<richard.guent...@gmail.com> wrote:
>
> 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" ;)
That's a very generous interpretation of "works" :-).
In that case I will make our code type agnostic, with the previously
attached patch (after testing). Then whenever SCEV and
bounds_of_var_in_loop (which also seems to be integer centric) support
floats, everything will just work.
Thanks.
Aldy
