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 rguent...@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)
