From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=He1y=HB=t-online.de=oleg.endo@sourceware.org>
Received: from mailout08.t-online.de (mailout08.t-online.de [194.25.134.20])
	by sourceware.org (Postfix) with ESMTPS id DE796385829A
	for <gcc-patches@gcc.gnu.org>; Mon, 20 Nov 2023 01:22:41 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DE796385829A
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=t-online.de
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=t-online.de
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DE796385829A
Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=194.25.134.20
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700443363; cv=none;
	b=cLL4Sx6yzB9Hf7MSxzGVIdzxCI2H0RogKJypQ7I9eSCUyhgvmPfd4cI6Ixn6NyNLTHoF6svaynSTUsq+katYSbU/DXzpEnLinxNEwuWlrErevgx0h0FMdZHXWLV5cJ0tPIPOvU8PgVP+DpmHGXv4kOKl5XXycm0xt0iaeUiLlVE=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1700443363; c=relaxed/simple;
	bh=HANIJWdzSgcW7xueev+/4rVzYERpQwrjFHgq3UMvJrY=;
	h=Message-ID:Subject:From:To:Date:MIME-Version; b=lNVwn5k9XzkW+N82y/m4Ks3Yi7GFB7ObjrDpP8+k7EwAVU+yH/nm0oVhax799jfvYzRdkX3ZpQgvJLNKXekQP2qEGKK/QsUVyyFtwaOgVwAgzh2OZXFgkq+zuBnS7MheBkV9hXYfjwv8T5LTkE2DT6NddO5blRacPqR3i1aZF9k=
ARC-Authentication-Results: i=1; server2.sourceware.org
Received: from fwd75.aul.t-online.de (fwd75.aul.t-online.de [10.223.144.101])
	by mailout08.t-online.de (Postfix) with SMTP id 7EAA21B60D;
	Mon, 20 Nov 2023 02:22:40 +0100 (CET)
Received: from localhost.localdomain ([115.165.108.210]) by fwd75.t-online.de
	with (TLSv1.3:TLS_AES_256_GCM_SHA384 encrypted)
	esmtp id 1r4szi-0n6sYC0; Mon, 20 Nov 2023 02:22:35 +0100
Message-ID: <5b865c34a380c7d08514ce5da8956d798e3478a8.camel@t-online.de>
Subject: Re: [RFA] New pass for sign/zero extension elimination
From: Oleg Endo <oleg.endo@t-online.de>
To: Jeff Law <jlaw@ventanamicro.com>, "gcc-patches@gcc.gnu.org"
	 <gcc-patches@gcc.gnu.org>
Cc: Jivan Hakobyan <jivanhakobyan9@gmail.com>
Date: Mon, 20 Nov 2023 10:22:31 +0900
In-Reply-To: <6d5f8ba7-0c60-4789-87ae-68617ce6ac2c@ventanamicro.com>
References: <6d5f8ba7-0c60-4789-87ae-68617ce6ac2c@ventanamicro.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
X-TOI-EXPURGATEID: 150726::1700443356-0D281850-A3347D7D/0/0 CLEAN NORMAL
X-TOI-MSGID: fc7da719-6f5a-416f-8f52-6ffb7c29615e
X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc-patches.gcc.gnu.org>


On Sun, 2023-11-19 at 17:47 -0700, Jeff Law wrote:
> This is work originally started by Joern @ Embecosm.
>=20
> There's been a long standing sense that we're generating too many=20
> sign/zero extensions on the RISC-V port.  REE is useful, but it's really=
=20
> focused on a relatively narrow part of the extension problem.
>=20
> What Joern's patch does is introduce a new pass which tracks liveness of=
=20
> chunks of pseudo regs.  Specifically it tracks bits 0..7, 8..15, 16..31=
=20
> and 32..63.
>=20
> If it encounters a sign/zero extend that sets bits that are never read,=
=20
> then it replaces the sign/zero extension with a narrowing subreg.  The=
=20
> narrowing subreg usually gets eliminated by subsequent passes (it's just=
=20
> a copy after all).
>=20

Have you tried it on SH, too?  (and if so any numbers?)

It sounds like this one would be great to remove some of the sign/zero
extension removal hackery that I've accumulated in the SH backend.

Cheers,
Oleg