From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0D098385AC2D; Wed, 19 Jan 2022 09:18:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0D098385AC2D From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102705] [12 Regression] Dead Code Elimination Regression at -O3 since r12-2637-g145bc41dae7c7bfa093d61e77346f98e6a595a0e Date: Wed, 19 Jan 2022 09:18:56 +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: 12.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: 12.0 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: Wed, 19 Jan 2022 09:18:57 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102705 --- Comment #2 from Richard Biener --- so it's _10 =3D=3D _10 ^ 1 vs. (short) _2 =3D=3D (short)(((char) _2) ^ 1) likely simplified using logical_inverted_value which works fine for the fir= st but not the second form. We're now doing more simplification (looking through some extra conversions), but that prevents this pattern from matchi= ng. By the time we compute the ranges necessary the conversions are already pickled too far before simplifying the conditional. Handling possible variants with patterns is a bit difficult, instead what looks necessary here is some sort of symbolic equivalence processing that would include bit ops so it tracks that _6 is _2 and _22 is _2 ^ 1. What would also help here is simplifying # RANGE [0, 1] NONZERO 1 _2 =3D 1 >> b.1_1; # RANGE [0, 1] NONZERO 1 iftmp.0_10 =3D (char) _2; # RANGE [0, 1] NONZERO 1 _4 =3D iftmp.0_10 ^ 1; # RANGE [0, 1] NONZERO 1 _5 =3D (int) _4; # RANGE [0, 1] NONZERO 1 iftmp.6_22 =3D (short int) _5; via ((char)_2) ^ 1 -> (char)(_2 ^ 1) though we generally do not widen ops. Which means doing it one level more outer at (int)((char) _2) ^ 1) -> _2 ^ 1 which is possible because the truncation is a no-op. That could be applied to all bit ops when we have range info on the non-constant operand for the case where the wider type fits in a GPR.=