From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id ED9FF385843E; Fri, 26 May 2023 15:21:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ED9FF385843E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1685114485; bh=1E812tjfyEv+GR+8H+3mV3/zVHIlmb8ewjewzAYn2H4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hm8QHuL86BwZTx/gknbDxcBIQNQvyR2FCw4/ZO0H6o0lqyfQ1LXhlkj/3c+eR4fKW uOQ/ECYwblHJJ0XsJI4OsEpyYUlbsQbKm0q90wP+qmDU7nWUdxKiDBCDuCA2wabeIe QyIxLYobNxhfnxA8yIHh7RmEdcvgVc53fgvGihKg= 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: Fri, 26 May 2023 15:21:25 +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: 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 --- Comment #22 from Andrew Pinski --- (In reply to Georg-Johann Lay from comment #20) > What then happens is: >=20 > expr.cc::do_store_flag() > expmed.cc::emit_store_flag_force() > expmed.cc::emit_store_flag() > expmed.cc::emit_store_flag_1() >=20 > the latter then does: >=20 > if (STORE_FLAG_VALUE =3D=3D 1 || normalizep) > /* If we are supposed to produce a 0/1 value, we want to do > a logical shift from the sign bit to the low-order bit; for > a -1/0 value, we do an arithmetic shift. */ > op0 =3D expand_shift (RSHIFT_EXPR, int_mode, op0, > GET_MODE_BITSIZE (int_mode) - 1, > subtarget, normalizep !=3D -1); >=20 > "normalizep" is true because ops->type has a precision of 1, and > STORE_FLAG_VALUE is the default of 1. >=20 > Nowhere is there any cost computation or consideration whether extzv could > do the trick. Thanks for tracking down where the shift is expanded to. Let me try to use extract_bit_field there instead (which should produce the better code).=