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 8BA773858D3C; Wed,  2 Nov 2022 00:46:16 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8BA773858D3C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1667349976;
	bh=osnD3ugpayrx8w9cvk6pwkQnxhB0JnlL7eu+tqiU4dg=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=sx1Px9dPZspuBJHcC88hSStLaGT5P/ejEw4p8lkmE6sGTQXgIXrtgW+d3GHqzmwoy
	 47pUpSmwoUcE7405vqLILrTIZZ6CrKwXYW+rh4bGCfB/2HJSUM0bAVluq3oQakh63U
	 gK+T3wz7JzQKlAotTGCNMtikAZWK8FcVTHXbqsgg=
From: "law at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/106602] riscv: suboptimal codegen for
 zero_extendsidi2_shifted w/o bitmanip
Date: Wed, 02 Nov 2022 00:46:16 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law 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: <bug-106602-4-uhdrNvbNa1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106602-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106602-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=3D106602

--- Comment #12 from Jeffrey A. Law <law at gcc dot gnu.org> ---
But insns 6, 7 and 8 aren't important here.  We have a REG_EQUAL on insn 9
which indicates that (reg:DI 77) has the value 0xffffffffffffffc0.  So I wo=
uld
have expected combine to substitute that into the use of (reg:DI 77) in ins=
n 10
which would give you a shot a recognizing the result is just a pair of shif=
ts.=20
But the REG_EQUAL doesn't seem to be used in that case.

My insn #s are different, but here's the relevant part of the dump:

Trying 9 -> 15:
    9: r139:DI=3Dr141:DI-0x40
      REG_DEAD r141:DI=20=20=20
      REG_EQUAL 0x3fffffffc0=20
   15: a0:DI=3Dr138:DI&r139:DI
      REG_DEAD r138:DI=20=20=20
      REG_DEAD r139:DI
Failed to match this instruction:=20
(set (reg/i:DI 10 a0)
    (and:DI (plus:DI (reg:DI 141)
            (const_int -64 [0xffffffffffffffc0]))
        (reg:DI 138)))

BUt we know the (and (plus ...))) is just 0x3fffffffc0, what's not clear is=
 why
we don't use that information and try to recognize=20

(set (reg:DI 10) (and (reg:DI 138) (const_int 0x3fffffffc0))

Which is just a pair of shifts.=