From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 56CE23858D37; Mon, 27 Mar 2023 08:09:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 56CE23858D37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1679904545; bh=KcunT8PE501Q0wmvxleQrqZzft9dQrKALnbzVCjVREw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=NrQR4BSnMjX9oOl+U0VJ0AUq40JKcJNFkngsBOe6an8a38D5nN+rsZd0LscusVL95 fpDN6JR9nhKVLwkZGJG7/s+7KmQxBuqYTVuQhLAVKBdr1eUkKtO/Hiv5MxLZDyO/xM 5gG385ArkUxbgdynn79g2cJTTZ7q/vrqRb5fHhMI= From: "rguenth at gcc dot 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 08:09: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: 13.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: 13.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109154 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #11 from Richard Biener --- (In reply to Andrew Macleod from comment #9) > (In reply to Richard Biener from comment #7) > > (In reply to Richard Biener from comment #6) > > > ah, probably it's the missing CSE there: > > >=20 > > > : > > > _1 =3D (float) l_10; > > > _2 =3D _1 < 0.0; > > > zone1_17 =3D (int) _2; > > > if (_1 < 0.0) > > >=20 > > > we are not considering to replace the FP compare control if (_1 < 0.0) > > > with an integer compare control if (_2 !=3D 0). Maybe we should do t= hat? > >=20 >=20 > That would resolve the issue from VRPs point of view. _2 has no involveme= nt > in the condition, sonother _2 nor zone1_17 are considered direct exports.= =20 >=20 >=20 > We do however recognize that it can be recomputed as it depends on _1. I > have not yet had a chance to extend relations to recomputations, (its > probably not a win very often as we assume CSE takes care fo those things) >=20 > I see we do make an attempt to recompute: >=20 > 13 GORI recomputation attempt on edge 3->4 for _2 =3D _1 < 0.0; > 14 GORI outgoing_edge for _1 on edge 3->4 > 15 GORI compute op 1 (_1) at if (_1 < 0.0) > GORI LHS =3D[irange] _Bool [1, 1] > GORI Computes _1 =3D [frange] float [-Inf, -0.0 (-0x0.0p+0= )] > intersect Known range : [frange] float VARYING +-NAN > GORI TRUE : (15) produces (_1) [frange] float [-Inf, -0.0 > (-0x0.0p+0)] > GORI TRUE : (14) outgoing_edge (_1) [frange] float [-Inf, -0.0 > (-0x0.0p+0)] > GORI TRUE : (13) recomputation (_2) [irange] _Bool VARYING >=20 > folding _2 using the true edge value: > [-Inf, -0.0 (-0x0.0p+0)] < 0.0=20 > is returning false, so we dont recognize that _2 is always true. I assume > this has something to do with the wonders of floating point and +/- 0:-) Yes, -0.0 is not < 0.0, it's equal. So the "bug" is > 15 GORI compute op 1 (_1) at if (_1 < 0.0) > GORI LHS =3D[irange] _Bool [1, 1] > GORI Computes _1 =3D [frange] float [-Inf, -0.0 (-0x0.0p+0= )] _1 shoud be [-Inf, nextafter (0.0, -Inf)], not [-Inf, -0.0] The issue seems to be that frange_nextafter used in build_lt uses real_nextafter and for 0.0 that produces a denormal (correctly so I think) but then we do flush_denormals_to_zero () in frange::set which makes a -0.0 out of this. Not sure why we treat denormals this way (guess we're just "careful"). "Fixing" this then yields GORI TRUE : (186) recomputation (_2) [irange] _Bool [1, 1] 3->4 (T) _2 : [irange] _Bool [1, 1] but this doesn't seem to help the PHI range in the successor? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Imports: _1 Exports: _1 _2 : _1(I) zone1_17 : _1(I) _2 l_10 [irange] int [-2147483646, 0] : _1 =3D (float) l_10; _2 =3D _1 < 0.0; zone1_17 =3D (int) _2; if (_1 < 0.0) goto ; [INV] else goto ; [INV] I don't see any recompute for zone1_17 from the [1,1] _2 we recomputed?=