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 8CFBD385772A; Sat, 22 Apr 2023 00:08:55 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8CFBD385772A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1682122135;
	bh=Bka2W8Y42S23ofUefSb+ITjIsdrkunacU/CVYXs61ZI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=GZ9YC2IjPOYJ6s3E/szD8Y5CdqczZn6tneSwyPb9ZcdzVUqkQGs3nQQniE4JnUBPD
	 Vm8byfrpCOg3rlk9HWNF4rFkKUF1Jk+x3smMlK67QicGCK//Swv5GYWHqrVzx8kVXV
	 0gYIgJRf5z/z+0ppYEKdozv+6ZsFlJK1IHN19bh8=
From: "vineetg at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/106888] [RISCV] Negative optimization that
 excess andi instructions are generated  in gcc.dg/pr90838.c
Date: Sat, 22 Apr 2023 00:08:55 +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: 13.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vineetg at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: <bug-106888-4-WxnAknBELM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106888-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106888-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=3D106888

--- Comment #9 from Vineet Gupta <vineetg at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #6)
> Comment on attachment 54905 [details]
> proposed patch
>=20
> So that's a subset of what we've done.  We initially thought that was goi=
ng
> to be enough to solve this class of problems.   But it's actually deeper
> than just having a zero_extension variant of this pattern.=20

Yeah it seems adding a new define_insn with zero_extend is not enough (nor =
is
the more elegant any_extend to existing "*<bitmanip_optab>disi2")

Thing is at expand time, we have gimple CTZ expand to ctz+sign_extend, so
adding zero_extend won't really help ?

(insn 6 3 7 2 (set (reg:SI 74)
        (ctz:SI (subreg/s/u:SI (reg/v:DI 73 [ x ]) 0))) "pr90838-red.c":11:=
15
-1
     (nil))
(insn 7 6 8 2 (set (reg:DI 72 [ <retval> ])
        (sign_extend:DI (reg:SI 74))) "pr90838-red.c":11:15 -1
     (nil))


> I'll officially submit the zero_extension pattern and the match.pd bits.=
=20
> The other pattern we wrote is fugly and I'd like to look at it one more t=
ime.

But that other pattern is needed for combine to fuse them together.=