[Bug tree-optimization/94043] [9/10 Regression] ICE in superloop_at_depth, at cfgloop.c:78

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 20 Mar 2020, linkw at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043
> 
> --- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #5)
> > On Fri, 20 Mar 2020, linkw at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043
> > > 
> > > --- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
> > > This was just exposed from my commit, it can also be reproduced without my
> > > commit but with -fno-vect-cost-model.
> > > 
> > > Some loops we have for this case:
> > > ;; Loop 1
> > > ;;  header 3, latch 10
> > > ;;  depth 1, outer 0
> > > ;;  nodes: 3 10 8 23 25 34 35 26 29 32 33 38 4 11 37 31
> > > 
> > > ;; Loop 2
> > > ;;  header 4, latch 11
> > > ;;  depth 2, outer 1
> > > ;;  nodes: 4 11
> > > 
> > > ;; Loop 4
> > > ;;  header 26, latch 29
> > > ;;  depth 2, outer 1
> > > ;;  nodes: 26 29
> > > 
> > > 
> > > When we are doing versioning for loop4 required for aliasing check, the related
> > >  scalar_loop_iters is based on e2.2_31, which is defined in BB 4, that is:
> > > 
> > >   <bb 4> [local count: 4343773762]:
> > >   # e2.2_31 = PHI <_15(11), 1(37)>
> > >   # ivtmp_14 = PHI <ivtmp_23(11), 4(37)>
> > > 
> > > 
> > > For the codes:
> > > 
> > >         if ((def_bb = gimple_bb (SSA_NAME_DEF_STMT (USE_FROM_PTR (use_p))))
> > >             && flow_bb_inside_loop_p (outermost, def_bb))
> > >           outermost = superloop_at_depth (loop, bb_loop_depth (def_bb) + 1)
> > > 
> > > bb_loop_depth is 2, the +1 make the assertion in superloop_at_depth fail since
> > > the current loop 4 only has the depth 2. I think the existing code has the
> > > assumption that all operands in stmts of cond_expr_stmt_list are defined in
> > > some outer loop of current, but the assumption breaks in this case.
> > > 
> > > I guess the current scalar_loop_iters is valid? Then the fix can be:
> > 
> > What is not valid I think is that e2.2_31 should have a loop-closed PHI
> > node which would place it in an outer loop.  You'd have to see why
> > either the loop-closed PHI is not present or why the aliasing check
> > doesn't use that (it's more likely this)
> > 
> 
> Thanks for the confirmation Richi! There is a loop-closed PHI for it in bb 33:
> 
>   <bb 4> [local count: 35145078524]:
>   # e2.2_31 = PHI <_15(11), 1(31)>
>   # ivtmp_14 = PHI <ivtmp_23(11), 4(31)>
>   _11 = (integer(kind=8)) e2.2_31;
>   _12 = _10 + _11;
>   _13 = _12 + -7;
>   hx[_13] = 0;
>   _15 = e2.2_31 + 1;
>   ivtmp_23 = ivtmp_14 - 1;
>   if (ivtmp_23 == 0)
>     goto <bb 33>; [11.00%]
>   else
>     goto <bb 11>; [89.00%]
> 
>   <bb 33> [local count: 3865958617]:
>   # _51 = PHI <_15(4)>
> 
> I'll further investigate why the scalar_loop_iters is constructed directly from
> e2.2_31 instead of _51.

It's most likely either SCEV or expand_simple_operations looking throuhg
the single-arg PHI (which we should avoid for LC PHI nodes)