From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E15B23858414; Fri, 5 Nov 2021 19:19:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E15B23858414 From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102950] [11/12 Regression] Dead Code Elimination Regression at -O3 (trunk&11.2.0 vs 10.3.0) Date: Fri, 05 Nov 2021 19:19:23 +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: amacleod at redhat dot com 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: 11.3 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, 05 Nov 2021 19:19:24 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102950 --- Comment #3 from Andrew Macleod --- Im not sure what the pre-ranger trick was, but the shortcoming we have it t= he following: a.0_1 =3D a; _2 =3D (int) a.0_1; _3 =3D _2 ^ 233; _4 =3D (unsigned int) _3; b_8 =3D (char) _3; a =3D b_8; if (b_8 !=3D 0) we know=20 _2 : int [-128, 127] but when we calculate _3,=20 [-128, 127] ^ 233 uses the original bitwise XOR code, and it returns VARYI= NG for that range. therefore We only know _3 is VARYING and therefore 2->3 (F) _3 : int [-INF, -256][0, 0][256, +INF] 2->3 (F) _4 : unsigned int [0, 0][256, 4294967040] When when we later get to=20 if (_4 <=3D 1) goto ; [25.50%] we're kinda of stuck. whereas in reality, properly calculated, we'd know that=20 _3 =3D [-128, 127], _4 =3D [-128, 127] And as you can see on the outgoing edges, we see thru the casts to trim out= the other bits in _3 and _4 on the 2->3 edge, so with those proper inputs, we would end up with _4 and _3 =3D=3D [0,0]. so, if no one else gets to it, I'll eventually teach range-op.cc::operator_bitwise_xor::wi_fold to do something about this. spe= cial case constants, or maybe look at the ranges and if the RHS fits within the = LHS effective precision, produce a better result.=