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 648803858D26; Wed, 25 Sep 2024 02:11:16 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 648803858D26
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1727230277;
	bh=SXzJswvwZOhYlBTXats6R78Vh9IQf9fIqKSY7J/pxHU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=nAy3MVth2C2M//vL2Cw93sRL18mc6/0+2ghiOnvONcylkjCD4ZAsH7hER5k2S0nnC
	 M2xARRSF79ppjt/MY1y20Abp0kqxSK4l6KnFTL9zIJCjpZEmqzLIebDsP4xo712j2S
	 +DTYEZSsWOZWBgZxUt2o+GveoTG6cha6DuV6L0ok=
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/55212] [SH] Switch to LRA
Date: Wed, 25 Sep 2024 02:11:04 +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: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo 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-55212-4-Gb3zcyxjgG@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55212-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55212-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=3D55212

--- Comment #322 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #316)
> (In reply to Oleg Endo from comment #314)
> > Can you please add the patch to your github branch?
> > I would like to ask some Dreamcast folks to try and test the GCC LRA br=
anch
> > with some bigger real-world software.  For that we need to have a "known
> > good state" of a branch on github.
>=20
> I've pushed the sfunc patch with lengthy sfunc patterns using
> hard_reg_r[456] + the patch in c#312 on the top of
>=20
> [59157] a revised patch to movsf issue which splits movesf_ie_ra
> [59158] a revised patch to QIHI extend/move
> [59153] Alex's patch works magically for call_pcrel* issue.
>=20
> as sh-lra-take3 branch of https://github.com/kazkojima/gcc.git.  Hope this
> helps.

Thanks!

I've also created a branch with your patches here:
https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dshortlog;h=3Drefs/heads/devel/sh-l=
ra

I've retouched the commits a little bit here and there, mainly in the comme=
nts
and commit messages.

If you have more patches or make a new branch, I will gradually merge them =
over
and try to keep the devel/sh-lra branch in a useful state.

With the current state, some open issues like PR 112115 are resolved.  But
others like PR 115949 or PR 113193 still remain.  Although those cases have
been also problematic before LRA as well.

I might be wrong, but I've got this feeling that whenever LRA hits the "rel=
oad
limit" it's an indicator that something is running in circles in the move-i=
nsn
pattern definitions.

I've noticed one thing.  The patch 'SH: pin input args to hard-regs via
predicates for sfuncs' skips the change for the patterns 'udivsi3_i4_int' a=
nd
'block_move_real_i4'.  Is this intentional or by accident?=