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 AC9873858417; Mon,  8 Nov 2021 14:19:42 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AC9873858417
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/102997] [12 Regression] 45% 454.calculix regression
 with LTO+PGO -march=native -Ofast on Zen since
 r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844
Date: Mon, 08 Nov 2021 14:19:42 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth 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.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-102997-4-VN2qu7qoTe@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-102997-4@http.gcc.gnu.org/bugzilla/>
References: <bug-102997-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: Mon, 08 Nov 2021 14:19:42 -0000

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

--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #25)
> (In reply to rguenther@suse.de from comment #24)
> > On Mon, 8 Nov 2021, hubicka at kam dot mff.cuni.cz wrote:
> >=20
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102997
> > >=20
> > > --- Comment #23 from hubicka at kam dot mff.cuni.cz ---
> > > > We verify that by simply looking at the loop depth relation of
> > > > the entry and exit of the path.
> > >=20
> > > Which seem wrong for the path leaving loop and entering another...
> >=20
> > True I guess.  The path should end it the same loop as it starts
> > or end in a loop containing the start loop.  Would have to double
> > check this.
>=20
> Yep, done:
>=20
>   // The path should either start and end in the same loop or exit the
>   // loop it starts in but never enter a loop.  This also catches
>   // creating irreducible loops, not only rotation.
>   if (entry->src->loop_father !=3D exit->dest->loop_father
>       && !flow_loop_nested_p (exit->src->loop_father,
>                               entry->dest->loop_father))
>     {
>       cancel_thread (&path, "Path rotates loop");
>       return true;
>     }

I suppose it might be more interesting to list what is allowed rather than
what is not.  We want to allow

 flow_loop_nested_p (exit->src->loop_father, entry->dest->loop_father)

plus entry->src->loop_father =3D=3D exit->dest->loop_father with extra
restrictions on the loop header not being crossed (but entry->src and
exit->dest could be the loop header - in the latter case we create
a subloop when we disambiguate the now multiple latches, in the
former case no harm is done).   The empty latch thing is only relevant
when we allow loop rotation which we don't.=