From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B3579385842E; Sat, 20 May 2023 22:40:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B3579385842E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1684622411; bh=PHv/4JroCD7fyOLs5uzxGV1Fz7z8in9gCTe1bnqdR/Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JItUYZntoXl7lurdWy+1GjRwgHd8wWl+MW2xJaQaNA5THDad+6hJ5cKYnVHkMuT1t LECVHrV3UR414Gr7BlileediEWwqQE7ZF8iMKLxweSteKK6BGOGQAjnjNI4/TYTQNF QLJI56Mxpz1wX7Fs7VB+OYZMbvwt+nXA9YFky1M4= From: "pinskia at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test) Date: Sat, 20 May 2023 22:40:11 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: pinskia 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: dependson 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=3D109907 Andrew Pinski changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|108847 | --- Comment #14 from Andrew Pinski --- Actually I take back on what is going on those 3. But I will be looking into it. x.0_1 =3D (signed long) x_4(D); _2 =3D x.0_1 >> 31; _3 =3D (unsigned char) _2; _5 =3D _3 & 1; That is what is causing arithmetic shift but we only need the first bit in = the end. If we optimized that to: x.0_1 =3D (unsigned long) x_4(D); _2 =3D x.0_1 >> 31; _3 =3D (unsigned char) _2; _5 =3D _3 & 1; similar to: uint8_t cset_32bit31_1 (uint32_t x) { if (x & (1ull<<31)) return 1; return 0; } Then there is still an issue. I have some ideas of how to handling the first case but I might need a few weeks. Note GCC 14 code generation here is similar now to GCC 4.5.x so that is the good news that this part is not a regression. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108847 [Bug 108847] unnecessary bitwise AND on boolean types and shifting of the "sign" bit=