From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 991293857C5A; Fri, 4 Aug 2023 07:59:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 991293857C5A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1691135974; bh=/ns7IFZOb8zRrRU8gcLSgvWwo8eLXe95J0rWFOMTQyY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pa6O0ipSbZ96P52HUGjWyEHtGsBhHdirZTnguD5EMmueluYZ9pa9+R+2Yi+ItLShS SGL97Bgyxsd/4fvWz5Dwu5O2tJ4T9YLwMZFY1aYVRrZIQ4zrO6LMKRLPO9sS7omEZW oYMp5FJ/xFRVDr+hHenxq5vW5qubfa2v7WKvuRuo= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/110891] [14 Regression] Dead Code Elimination Regression since r14-2674-gd0de3bf9175 Date: Fri, 04 Aug 2023 07:59:33 +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: 14.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110891 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amacleod at redhat dot com --- Comment #2 from Richard Biener --- I didn't anticipate the trick triggering with FRE but we have Value numbering stmt =3D _6 =3D _5 | 64; Setting value number of _6 to _6 (changed) ... Value numbering stmt =3D _9 =3D _8 & 5; Setting value number of _9 to _9 (changed) ... Replaced a with _6 in all uses of _8 =3D a; Applying pattern match.pd:184, gimple-match-10.cc:6142 Applying pattern match.pd:1962, gimple-match-6.cc:16850 gimple_simplified to _10 =3D _5 & 5; _9 =3D _10; that's the old issue that when we are recursively simplifying pattern results like (bit_ior (bit_and @0 @2) (bit_and! @1 @2))) we need to push operands, but when any outer operation simplifies away we can't (or rather do not) pop them again (also when asked to never push we'd fail the pattern before trying to simplify the outer operation). That can then result in such stray copies to appear. So the first IL difference is --- a/t.c.114t.fre3 2023-08-04 09:22:55.380428835 +0200 +++ b/t.c.114t.fre3 2023-08-04 09:21:50.455470894 +0200 @@ -159,7 +159,7 @@ a =3D _6; _10 =3D _5 & 5; _9 =3D _10; - a =3D _9; + a =3D _10; return 0; } but that vanishes in copyprop1. ifcombine then gets different SSA names assigned which means different association of bitwise or operations. For some reason this causes the divergence in DOM2. After copyprop2 we have -FREE_SSANAMES: 12, 21, 3, 4, 7, 16, 15, 19, 22, 26, 17, 27, 13, 6, 20, 25,= 8, 18, 24, 9,=20 +FREE_SSANAMES: 12, 21, 3, 4, 7, 16, 15, 19, 22, 26, 17, 27, 9, 13, 6, 20, = 25, 8, 18, 24,=20 so the same SSA names are in the freelist but as that is unordered we pick different names when re-using. In the DOM2 pass you can see that ranger behaves slightly different when processing operands in different order for commutative operations like bitwise or in this case, that leads to the observed difference in threading. Tracing ranger reveals too many differences, in the end I'd say "bad luck", but maybe ranger folks want to investigate as well? I'm not convinced we need to sort FREE_SSANAMES, solving the slightly imperfect simplification for match would be nice.=