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 60F223857C48; Thu, 20 Jan 2022 14:12:04 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 60F223857C48
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/103721] [12 regression] wrong code generated
 for loop with conditional since r12-4790-g4b3a325f07acebf4
Date: Thu, 20 Jan 2022 14:12:03 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amacleod at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
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-103721-4-JrPdZdpR7M@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-103721-4@http.gcc.gnu.org/bugzilla/>
References: <bug-103721-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: Thu, 20 Jan 2022 14:12:04 -0000

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

--- Comment #14 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Aldy Hernandez from comment #11)
> <bb 3> [local count: 1063004409]:
>  # j_17 =3D PHI <j_2(9), 0(2)>
>  # q_18 =3D PHI <prephitmp_16(9), &a(2)>
>

>   <bb 5> [local count: 1063004409]:
>   # j_2 =3D PHI <j_8(4), 0(3)>
>   # prephitmp_16 =3D PHI <_14(4), &a(3)>
>   if (prephitmp_16 =3D=3D q_18)
>     goto <bb 6>; [0.00%]
>   else
>     goto <bb 7>; [100.00%]
>=20
>   <bb 9> [local count: 1052374367]:
>   goto <bb 3>; [100.00%]
>=20
> Even if we reset relations and clear the root oracle at the backedge (9->=
3),
> we still get the _16 =3D=3D _18 in BB3, followed by the DEF of _16 in BB5.

Well, you cant add that relation either..    although you have cleared the
existing relations when you traverse the back edge, you are then immediately
adding another one FROM the backedge (9->3) which is a value from the previ=
ous
iteration... so it cant be used.=20

You need to also stipulate that if you are adding an equivalence from a PHI
like that, it is not a back edge you are adding from.


And I think it is probably safe to "reset" the root oracle to search for
relations from top of the loop, assuming it dominates the latch it came fro=
m.=20
Any new relations are going to now be dominated by this block.=