From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 3E94C3858C41; Fri, 19 May 2023 20:41:52 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3E94C3858C41
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1684528912;
	bh=c9kZx7as623rwA8uXDd/KF1bzlNkWkjwcgMFpIcoz0M=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Ay9u8XcSVfNYhOt2rVltvqnnEFf6Po27GqrYbCA88DvoVfQvBTFjwLj7EE612NSsH
	 kYkYURs//Yn+cVJ8o+jNt8DzG6wLRcGdP/YKub6uei3nIVlOvuG3SkQNosHSYSU06A
	 VbcZKECmifnUWiLMTYk03qVbnkiWrtOYjRBVBfNU=
From: "gjl at gcc dot gnu.org" <gcc-bugzilla@gcc.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, 19 May 2023 20:41:51 +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: gjl at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: pinskia at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-109907-4-ewE9GcFVVg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109907-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109907-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109907

--- Comment #6 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> For cset_32bit30_not with some patches which I will be posting, I get:
>         bst r25,6        ;  23  [c=3D4 l=3D3]  *extzv/4
>         clr r24
>         bld r24,0
>         ldi r25,lo8(1)   ;  24  [c=3D4 l=3D1]  movqi_insn/1
>         eor r24,r25      ;  25  [c=3D4 l=3D1]  *xorqi3
> /* epilogue start */
>         ret              ;  28  [c=3D0 l=3D1]  return
>=20
> Which is better than what was there before.

Quite impressive improvement.  Maybe the last step can be achieved with a
combiner pattern that combines extzv with a bit flip.

One problem is usually that there is no canonical form (sometimes zero_extr=
act,
sometimes shift+and, sometimes with subregs for extraction or paradoxical
subregs for wider types, different behaviour for MSB, etc.).

avr's extzv currently reads

(define_expand "extzv"
  [(set (match_operand:QI 0 "register_operand")
        (zero_extract:QI (match_operand:QI 1 "register_operand")
                         (match_operand:QI 2 "const1_operand")
                         (match_operand:QI 3 "const_0_to_7_operand")))])

Maybe QI for op1 is not optimal, but it's not possible to use mode iterator
because there's only one gen_extzv.  Dunno if VOIDmode would help or is san=
e.

> The first one I suspect load_extend_op for SImode returning SIGN_EXTEND f=
or
> avr.

It's not implemented for avr, thus UNKNOWN as of defaults.h.=