From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 842FD3945C3C; Fri, 20 Mar 2020 07:22:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 842FD3945C3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1584688954; bh=n5HbZFrFUBa0Vuc0XQTAW7Kf2A/uwj6j4iJ8xXCkfn4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Z38nqxhJEzCrnKfyehRy6GbVjmY5sDSWczbUjWqxG6zstvf0YfvpG2THEM1wbbFZ3 SH5tflHm5QALa6xgKBCBJjIBL5pVgp8WgcWi+TsdcBC0OPOntJU+wnuJXc6FQM+Qmd Ml7kZt+WqxIoB0WrM/qMMOetTqDs9bUDMJfKmoIw= 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:22:34 +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:22:34 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94043 --- Comment #7 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 #6 from Kewen Lin --- > (In reply to rguenther@suse.de from comment #5) > > On Fri, 20 Mar 2020, linkw at gcc dot gnu.org wrote: > >=20 > > > 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 witho= ut 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, t= he related > > > scalar_loop_iters is based on e2.2_31, which is defined in BB 4, tha= t 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 (u= se_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 f= ail since > > > the current loop 4 only has the depth 2. I think the existing code ha= s the > > > assumption that all operands in stmts of cond_expr_stmt_list are defi= ned 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: > >=20 > > 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) > >=20 >=20 > Thanks for the confirmation Richi! There is a loop-closed PHI for it in b= b 33: >=20 > [local count: 35145078524]: > # e2.2_31 =3D PHI <_15(11), 1(31)> > # ivtmp_14 =3D PHI > _11 =3D (integer(kind=3D8)) e2.2_31; > _12 =3D _10 + _11; > _13 =3D _12 + -7; > hx[_13] =3D 0; > _15 =3D e2.2_31 + 1; > ivtmp_23 =3D ivtmp_14 - 1; > if (ivtmp_23 =3D=3D 0) > goto ; [11.00%] > else > goto ; [89.00%] >=20 > [local count: 3865958617]: > # _51 =3D PHI <_15(4)> >=20 > I'll further investigate why the scalar_loop_iters is constructed directl= y 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)=