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 659EF3857806; Tue,  6 Jun 2023 10:51:02 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 659EF3857806
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1686048662;
	bh=ph1xzrl1ESWok2SUHizPzdDTSxjLeGjstixRNaD0TZ8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=fpqc1AH5bu+dVAJ7UUFYioKxDLajOlo7na7AtWebbPyVaJQJHJAOVdG2JTqfl1uTM
	 PACcr4kTZJEdpcrKsp6uDLH3L6Xm4dSv2Fc1dd3lJCYPPIKVS4Rh4Jf37sQ63KM8W2
	 a4X2TFmldq9UUy5AqOvcf3U/FBQiYliMa3gdshDk=
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/54089] [SH] Refactor shift patterns
Date: Tue, 06 Jun 2023 10:51:01 +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.8.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
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-54089-4-zzfmtYjSbV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-54089-4@http.gcc.gnu.org/bugzilla/>
References: <bug-54089-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=3D54089

--- Comment #61 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Alexander Klepikov from comment #60)
> > Maybe it's easier to add some shift specific passes.
>=20
> Well, I couldn't think of anything better and ported the loop optimization
> pass. More precisely, all loop optimization passes, because they are tied=
 to
> each other. They run after split1 pass. And it worked!
>=20
> I want to beleive that another loop optimization pass won't break anything
> because loops are already optimized.

Theoretically it should't ...=20

>=20
> If that's redundant, I thought of expanding libcall if it's inside a loop
> before loop optimization passes.

I'm a bit concerned about the increased compile time.  Have you observed
anything (negative) in this regard?

Loop, hoist, constant propagation etc (+ all the good stuff) optimizations =
are
done before insn combine / split1.  We could add a simple SH specific pass =
that
goes over the RTL and does stuff to shifts before those other optimizations=
.=20
However, it might miss insn combine opportunities later on.  I'm thinking a=
bout
your tst #imm,r0 case from before.=