From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DE0133945C29; Fri, 20 Mar 2020 07:06:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DE0133945C29 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1584687985; bh=orPGRj7blWklBsbliVT8QrGNggj4DVaZ8E3EE1F+OA8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vN3fw0VktJBzpaoW7IyF0B/UlzyvaPxtbh2RLWyQ68PzTZuBEzBBCl3gz7ANsxdy6 rNF3tHGPl1GXaQs8E4nHI70d03i0ycLSo458Qvf/KtShc1+PmNxpgl5epoC7F+gANZ RXLcmuqcjjTmtZzhMmk+9Jm624tMeHD5Jjx/29gU= From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/94043] [9/10 Regression] ICE in superloop_at_depth, at cfgloop.c:78 Date: Fri, 20 Mar 2020 07:06:25 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: linkw at gcc dot gnu.org X-Bugzilla-Target-Milestone: 9.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 07:06:26 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94043 --- Comment #5 from 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=3D94043 >=20 > --- Comment #4 from Kewen Lin --- > This was just exposed from my commit, it can also be reproduced without my > commit but with -fno-vect-cost-model. >=20 > 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 >=20 > ;; Loop 2 > ;; header 4, latch 11 > ;; depth 2, outer 1 > ;; nodes: 4 11 >=20 > ;; Loop 4 > ;; header 26, latch 29 > ;; depth 2, outer 1 > ;; nodes: 26 29 >=20 >=20 > When we are doing versioning for loop4 required for aliasing check, the r= elated > scalar_loop_iters is based on e2.2_31, which is defined in BB 4, that is: >=20 > [local count: 4343773762]: > # e2.2_31 =3D PHI <_15(11), 1(37)> > # ivtmp_14 =3D PHI >=20 >=20 > For the codes: >=20 > if ((def_bb =3D gimple_bb (SSA_NAME_DEF_STMT (USE_FROM_PTR (use_p= )))) > && flow_bb_inside_loop_p (outermost, def_bb)) > outermost =3D superloop_at_depth (loop, bb_loop_depth (def_bb) = + 1) >=20 > 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. >=20 > 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) > --- a/gcc/tree-vect-loop-manip.c > +++ b/gcc/tree-vect-loop-manip.c > @@ -3312,7 +3312,13 @@ vect_loop_versioning (loop_vec_info loop_vinfo, > FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_USE) > if ((def_bb =3D gimple_bb (SSA_NAME_DEF_STMT (USE_FROM_PTR (use_p= )))) > && flow_bb_inside_loop_p (outermost, def_bb)) > - outermost =3D superloop_at_depth (loop, loop_depth (outermost) = + 1); > + { > + /* Def block can be in either one outer loop of loop_to_versi= on or > + one sibling of outer loop of loop_to_version. */ > + class loop *common_loop > + =3D find_common_loop (def_bb->loop_father, loop); > + outermost =3D superloop_at_depth (loop, loop_depth (common_lo= op) + > 1); > + } > } >=20 >=