From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F119E3858D33; Tue, 14 Feb 2023 21:28:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F119E3858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1676410087; bh=muHq+A99qRDf4CepiwrniazW4nDFVxPmbqsn3eBk8BY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FESGOXSWgzvfHL8Cw/VEPYBa6BugTnlK9AW016xzN8dje8/EiiCpn47SmZHkkVyai 33Z7YxHuztHEz9imAGIc0wfhZbjWwh3mmlzR6YEoW35MnJ5dtiQim2Q5VRfTH+rDcu mTP2Cntm4zK8A01AVWyxWvRCo7bPSYi8gnPpdzNA= From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107972] backward propagation of finite property not performed Date: Tue, 14 Feb 2023 21:28:06 +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: amacleod at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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=3D107972 --- Comment #5 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #3) > The backwards propagation fixed, but neither: <...> > avoids the 4.2e+1 cases in the output, because in neither case we properly > determine the ranges of res (that it is in foo/bar/baz/qux > [-DBL_MAX,DBL_MAX]). > For quux I think we don't have a way to represent that right now, we'd ne= ed > a union of 2 ranges and after all, we also flush denormals to zero, so I > think we'd need if (!(res < 1.0)) __builtin_unreachable (); or > __attribute__((assume (res < 1.0))); so that we get [1.0, +INF] non-NAN > range. > Aldy/Andrew, any ideas what's going on? Relooking at this, I am confused a bit. First, how can we remove the 42.0 from the output? I see no reason the ca= ller can't pass a NAN in for a or b, and then the first if will trigger and retu= rn 42? Sure, once we get to the calculation of res and know its not a NAN, we also know the first if wasn't necessary, but thats only true if we actually get = past that first If...? Second, we do actually know res is is that range on the outgoing edge if the if.. ie for quux: res_8 =3D a_7(D) / b_6(D); _2 =3D res_8 unord res_8; _3 =3D res_8 =3D=3D 0.0; _4 =3D _2 | _3; if (_4 !=3D 0) goto ; [INV] else goto ; [INV] 4->5 (T) _4 : [irange] _Bool [1, 1] 4->5 (T) b_6(D) : [frange] double [-1.79769313486231570814527423731704356798070567525844996599e+308 (-0x0.fffffffffffff8p+1024), 1.79769313486231570814527423731704356798070567525844996599e+308 (0x0.fffffffffffff8p+1024)] 4->5 (T) res_8 : [frange] double [-0.0 (-0x0.0p+0), 0.0 (0x0.0p+0)] +-NAN 4->6 (F) _2 : [irange] _Bool [0, 0] NONZERO 0x0 4->6 (F) _3 : [irange] _Bool [0, 0] NONZERO 0x0 4->6 (F) _4 : [irange] _Bool [0, 0] NONZERO 0x0 4->6 (F) b_6(D) : [frange] double [-1.79769313486231570814527423731704356798070567525844996599e+308 (-0x0.fffffffffffff8p+1024), 1.79769313486231570814527423731704356798070567525844996599e+308 (0x0.fffffffffffff8p+1024)] 4->6 (F) a_7(D) : [frange] double [-Inf, +Inf] 4->6 (F) res_8 : [frange] double [-Inf, +Inf] We know on the edge 4->6 res_8 can't be a NAN (I think we have no way to al= so represent ~0.0 right now, true) We don't set the global that way due to some restrictions of the way we currently remove unreachable(). there are 2 uses of res_8 in the expressio= ns in that block which ranger is currently not comfortable propagating the [-I= nf, +Inf] into since they precede the condition itself... it currently only dea= ls with this situation if there is ONE use in a condtion. Since this has 2, it gives up on this release.=20 On the reachable edge leading to the return, in each of the 4 cases we know= res is not a NAN. we just dont reflect it in the global always. Next release I plan to revamp the unreachable stuff... again. so many nooks and crannies :-)=