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 D55EF3858C1F; Tue, 28 Mar 2023 13:52:40 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D55EF3858C1F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1680011560;
	bh=/1dx8/bz2f/He0GQBSSFsJttW+3ro/kUuQgzmX5lGho=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ceh9IoFKmtDJbwIgMPrZ3Mmj3pP62897rDHTI1JOC1acVj7lGiCiEdNAOtR6qkXIc
	 5gAZqRjQzbKYZSxDXz69u6WHFsvXDnTWWlGn5ywrrcgkCRd2KuOg97aDDixd97zCiL
	 WAEOsBSr4wyCIPPw5AHGkD8iK2W2Ku2d4To/TAKs=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109154] [13 regression] jump threading
 de-optimizes nested floating point comparisons
Date: Tue, 28 Mar 2023 13:52:37 +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: 13.0
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: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-109154-4-7rCGRd5FoM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109154-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109154-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=3D109154

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
On the #c28 testcase, my #c23 patch seems to improve something only visible=
 in
the details of the evrp dump:
 zone1_12 : [irange] int [0, 1] NONZERO 0x1
-2->3  (T) _1 :         [frange] float [-Inf, -0.0 (-0x0.0p+0)]
+2->3  (T) _1 :         [frange] float [-Inf,
-1.40129846432481707092372958328991613128026194187651577176e-45 (-0x0.8p-14=
8)]
+2->3  (T) _2 :         [irange] _Bool [1, 1]
 2->4  (F) _1 :         [frange] float [-0.0 (-0x0.0p+0), +Inf] +-NAN
So, at least it knows that _2 =3D _1 < 0.0; is true on that edge, which is a
progress.
But seems it doesn't know that zone1_12 =3D (int) _2; is also int [1, 1] th=
ere
and so
the
  # iftmp.0_8 =3D PHI <zone1_12(3), 1(2)>
range would be int [1, 1] too.
I think we are here outside of the frange stuff and into GORI.

Andrew, could you please have a look?=