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 1AC043858C53; Mon, 27 Mar 2023 10:18:15 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1AC043858C53
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1679912295;
	bh=o0kepTP7bHu9Gg17myGuxmr3ZuxlhpTed5hmerWFLZ0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ej+yBPLFfYkpIZAPRBrn9c2ZwsWijq25GXkJzS9dVR5mGT2325gd9YxM5DppdrQI2
	 0HMFodY77P+M/vhjVU+4kM+SH1T1xQnQCa5Eck3ktO+bqPdqkTK+k/3cEph+R/knz6
	 O2sgj2r/c+vWnz/013XBfJFmTJ55z4FgfRBkkXEA=
From: "rguenther at suse dot de" <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: Mon, 27 Mar 2023 10:18:13 +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: rguenther at suse dot de
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-3cIfzNKgjx@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 #15 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 27 Mar 2023, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109154
>=20
> --- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #11)
> > _1 shoud be [-Inf, nextafter (0.0, -Inf)], not [-Inf, -0.0]
>=20
> Well, that is a consequence of the decision to always flush denormals to =
zero
> in
> frange::flush_denormals_to_zero, because some CPUs do it always and other=
s do
> it when asked for (e.g. x86 if linked with -ffast-math).
> Unless we revert that decision and flush denormals to zero only selective=
ly
> (say on alpha in non-ieee mode (the default), or if fast math (which exact
> suboption?) etc.

I think flushing denormals makes sense for "forward" propagation,
aka computing LHS ranges.  For ranges derived from relations it
really hurts (well, just for compares against zero).

OTOH, if you consider

 _1 =3D a[1]; // load from a denormal representation
 if (_1 < 0.)

then whether _1 should include -0.0 or not depends on what the target
does on the load.  I suppose the standard leaves this implementation
defined?

Given -ffast-math on x86 enables FTZ we'd have to be conservative there
as well.  But OTOH we don't have any HONOR_DENORMALS or so?

Note the testcase in this PR was about -Ofast ...=