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).
Thanks so much for looking at this.
Aldy
