On Wed, Oct 14, 2020 at 4:19 PM Aldy Hernandez <al...@redhat.com> wrote:
>
>
>
> On 10/14/20 9:43 AM, Richard Biener wrote:
> > On Tue, Oct 13, 2020 at 6:12 PM Aldy Hernandez <al...@redhat.com> wrote:
> >>
> >>
> >>
> >> On 10/13/20 6:02 PM, Richard Biener wrote:
> >>> On October 13, 2020 5:17:48 PM GMT+02:00, Aldy Hernandez via Gcc-patches
> >>> <gcc-patches@gcc.gnu.org> wrote:
> >>>> [Neither Andrew nor I are familiar with the SCEV code. We treat it as
> >>>> a
> >>>> black box :). So we could use a SCEV expert here.]
> >>>>
> >>>> In bounds_of_var_in_loop, evolution_part_in_loop_num is returning NULL:
> >>>>
> >>>> step = evolution_part_in_loop_num (chrec, loop->num);
> >
> > (*)
> >
> >>>
> >>> It means that Var doesn't vary in the loop.
> >>> That is, chrec isn't a polynomial chrec.
> >>
> >> That's what I thought, but it is:
> >>
> >> (gdb) p chrec
> >> $6 = <polynomial_chrec 0x7ffff0e2a820>
> >> (gdb) dd chrec
> >> {0, +, 1}_2
> >>
> >> evolution_part_in_loop_num() is returning NULL deep in
> >> chrec_component_in_loop_num():
> >>
> >> default:
> >> => if (right)
> >> return NULL_TREE;
> >> else
> >> return chrec;
> >>
> >> Do you have any suggestions?
> >
> > I can only guess (w/o a testcase) that loop->num at (*) is not 2 and thus
> > that
> > chrec does not evolve in the loop we're asking. But this doesn't make much
> > sense with the constraints we are calling this function (a loop header PHI
> > with loop == the loop and stmt a loop header PHI and var the PHIs lhs).
> >
> > OK, so looking at the testcase you're doing
> >
> > 492 class loop *l = loop_containing_stmt (phi);
> > 493 if (l)
> > 494 {
> > 495 range_of_ssa_name_with_loop_info (loop_range,
> > phi_def, l, phi);
> >
> > but 'l' isn't a loop, it's the loop tree root. Change to
> >
> > if (l && loop_outer (l))
>
> Woah. I did not expect that.
>
> A quick peek shows that all users of bounds_of_var_in_loop (through
> adjust_range_with_scev) predicate the call with:
>
> && l->header == gimple_bb (phi))
>
> If this check is similar to the loop_outer(l) you suggest, could we
> perhaps push this check (and/or the loop_outer one) into
> bounds_of_var_in_loop itself and remove it from all the callers? It
> seems cleaner to have this check in one place, than in three different
> places. That is, unless the l->header check is altogether a different
> thing than loop_outer(l).
The code also works for stmts other than PHIs (or stmts in other blocks
than the loop header), so IMHO is not appropriate for bounds_of_var_in_loop.
Richard.
>
> Thanks so much for looking at this.
> Aldy
>
