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 C071E3857BB2; Tue, 30 Jan 2024 10:32:08 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C071E3857BB2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1706610728;
	bh=vUVB5F5HQ/X46NvQVZQWVHWyrJ2WoXZNxS3Gg1sBmMc=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=nhLGtRE4wUNj0GJ99S9Y/RwMmvHc9KOo0Ciwm8oTRVemh0hcsunci1mizRgCUfywR
	 FKJn6KAQaWUWcAEgDyjK80/XG/RhxdikLoHz0Lrk5E6r+k7PPalyMkgdZhC0hKmWY2
	 VM3d9UlOHKzqHKhddrqEBntk4hBZNR55O2bw7Atk=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/113059] [14 regression] fftw fails tests for -O3 -m32
 -march=znver2 since r14-6210-ge44ed92dbbe9d4
Date: Tue, 30 Jan 2024 10:32:07 +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: 14.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-113059-4-rJ7Qt9mlNb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113059-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113059-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=3D113059

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #17)
> (In reply to Jakub Jelinek from comment #16)
> > The question is revert what exactly?
> > If we revert r14-6210, we get back the other P1.  Or do you mean revert
> > r14-5355?
> > I guess another option is move the vzeroupper pass one pass later, i.e.
> > after pass_gcse.
>=20
> I think moving mdreorg passes as late as possible esp. when they don't pl=
ay
> well with DF/notes is a good thing.  Maybe even after pass_rtl_dse2 and
> thus after shrink-wrapping?

The thing is that the vzeroupper pass actually plays well with DF notes, the
problem is that it now (in GCC 14) asks for them to be computed.
The first issue was that vzeroupper before postreload_cse computed the note=
s,
then
postreload_cse CSEd something and made the REG_UNUSED invalid without killi=
ng
them and then later passes went wrong because of the incorrect notes.
This issue is that vzeroupper now after postreload_cse but before gcse2
computes notes, then gcse2 CSEs something and makes REG_UNUSED invalid, res=
t is
the same.
But, I believe gcse2 is the last CSE-ish pass.
I wouldn't move it too much further, because I don't remember the interacti=
ons
between vzeroupper, splitting and peepholes.=