On Tue, Aug 2, 2022 at 2:11 PM Aldy Hernandez <al...@redhat.com> wrote:
>
> 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.
Sounds good.
Richard.
> Thanks.
> Aldy
>
