From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2A0AF385BF86; Sun, 22 Mar 2020 08:39:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2A0AF385BF86 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1584866385; bh=OAvjPbwAI3rLyTIfY72+0kTeqF9Q44lLawvletFgmE0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VfwCRvbh6aX4gpdKzN+MkYztXAu3S5Ow5CpncjCttyOiTkjJcMdEY4mjgLhHw6CiQ MegK8VlDWyhsG2evFn2wBia6rprIVwqdvhBqM8IYBxu40/LKFPKUOvWIlAjS+5zjm5 6srxXuXO5ebWhMYSl0MkvDnr+a7icUHgcr4DUMNM= From: "linkw at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/94043] [9/10 Regression] ICE in superloop_at_depth, at cfgloop.c:78 Date: Sun, 22 Mar 2020 08:39:44 +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: linkw at gcc dot gnu.org 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: Sun, 22 Mar 2020 08:39:45 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94043 --- Comment #8 from Kewen Lin --- > It's most likely either SCEV or expand_simple_operations looking throuhg > the single-arg PHI (which we should avoid for LC PHI nodes) Thanks Richi, I found the loop-closed PHI form was broken after we finished= the vectorization on the loop 2, BB 38 was inserted, the function gimple_find_edge_insert_loc will get one new BB if the dest has phis, even = it's unrelated. ;; basic block 4, loop depth 2 ;; pred: 11 ;; 37 ... _15 =3D e2.2_31 + 1; ... if (ivtmp_59 >=3D 1) goto ; [100.00%] else goto ; [0.00%] ;; succ: 38 ;; 11 ;; basic block 38, loop depth 1 ;; pred: 4 _40 =3D BIT_FIELD_REF ; ;; succ: 33 ;; basic block 33, loop depth 1 ;; pred: 38 # _51 =3D PHI <_15(38)>=20 ;; succ: 34 The alternatives seems could be 1) extend the current gimple_find_edge_insert_loc to handle the phi nodes, if the phis aren't related, just insert there, otherwise, insert some phis for uses of those s= tmts and remove the related phis and create new assignments after those new stmt= s, or 2) call rewrite_into_loop_closed_ssa for each successful vectorization.=