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 BBFE738560BA; Fri, 24 Jun 2022 17:33:54 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BBFE738560BA
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/105930] [12/13 Regression] Excessive stack spill
 generation on 32-bit x86
Date: Fri, 24 Jun 2022 17:33:54 +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: 12.1.1
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub 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: 12.2
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-105930-4-RMquKxlKgQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-105930-4@http.gcc.gnu.org/bugzilla/>
References: <bug-105930-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jun 2022 17:33:54 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105930

--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Linus Torvalds from comment #23)
> (In reply to Jakub Jelinek from comment #22)
> >=20
> > If the wider registers are narrowed before register allocation, it is j=
ust
> > a pair like (reg:SI 123) (reg:SI 256) and it can be allowed anywhere.
>=20
> That was more what I was thinking - why is the DImode information being k=
ept
> so long?

This is what is being discussed here.
Some possibilities are lower these multi-word operations during expansion f=
rom
GIMPLE to RTL (after all, the generic code usually does that without anythi=
ng
special needed on the backend side unless one declares the backend can do t=
hat
better), one counter-argument to that is the x86 STV pass which uses vector
operations for 2 word operations when possible and it won't really work whe=
n it
is lowered during expansion.

Another is splitting those before register allocation, which is what some
patterns did and what other patterns didn't.

Or it can be split after register allocation.

My understanding was that Roger tried to change some patterns from splitting
after RA to before RA and it didn't improve this testcase, so in the end
changed some other patterns from splitting before RA to after RA.=