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 A288D385843E; Fri, 26 May 2023 17:44:31 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A288D385843E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1685123071;
	bh=kcrtc2vVDSjdnCZwmjfPogfGJzFqEotIoiJzLsmD5HI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=attQLrRXP6TxV/LbSoJU3ilEwuqdcxZcKQUfv1X6kZZzz6ml4/PgYxy+Dvf4eXYHH
	 m4qGuzhqEcHcXa6vBMIOKvqE/bUPxatfS4mMREbnECkpo+5bG9nv7Pgt1EA2ISz60O
	 mZXD+/kL+oBAEos+fP3rjq5r8kG54t4UEiRmjBFM=
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/49263] SH Target: underutilized "TST #imm, R0"
 instruction
Date: Fri, 26 May 2023 17:44:30 +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: 4.6.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: olegendo at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-49263-4-0m049SYyS6@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-49263-4@http.gcc.gnu.org/bugzilla/>
References: <bug-49263-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=3D49263

--- Comment #42 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Alexander Klepikov from comment #41)
>=20
> Thank you! I have an idea. If it's impossible to defer initial optimizati=
on,
> maybe it's possible to emit some intermediate insn and catch it and optim=
ize
> later?

This is basically what is supposed to be happening there already.

However, it's a bit of a dilemma.

1) If we don't have a dynamic shift insn and we smash the constant shift in=
to
individual=20
stitching shifts early, it might open some new optimization opportunities, =
e.g.
by sharing intermediate shift results.  Not sure though if that actually
happens in practice though.

2) Whether to use the dynamic shift insn or emit a function call or use
stitching shifts sequence, it all has an impact on register allocation and
other instruction use.  This can be problematic during the course of RTL
optimization passes.

3) Even if we have a dynamic shift, sometimes it's more beneficial to emit a
shorter stitching shift sequence.  Which one is better depends on the
surrounding code.  I don't think there is anything good there to make the
proper choice.

Some other shift related PRs: PR 54089, PR 65317, PR 67691, PR 67869, PR 52=
628,
PR 58017


> > BTW, have you tried it on a more recent GCC?  There have also been some
> > optimizations in the middle-end (a bit more backend independent) for th=
is
> > kind of thing.
>=20
> I tried 13.1 about week or two ago with the same result.
>=20

Good to know.  Thanks for checking it!=