From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 91CA2385843B; Wed, 9 Feb 2022 18:30:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 91CA2385843B From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/24021] VRP does not work with floating points Date: Wed, 09 Feb 2022 18:30:32 +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: 4.1.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2022 18:30:33 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D24021 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- Various match.pd patterns use predicates like: (simplify (mult @0 real_zerop@1) (if (!tree_expr_maybe_nan_p (@0) && (!HONOR_NANS (type) || !tree_expr_maybe_infinite_p (@0)) && (!HONOR_SIGNED_ZEROS (type) || tree_expr_nonnegative_p (@0))) @1)) /* In IEEE floating point, x*1 is not equivalent to x for snans. Likewise for complex arithmetic with signed zeros. */ (simplify (mult @0 real_onep) (if (!tree_expr_maybe_signaling_nan_p (@0) && (!HONOR_SIGNED_ZEROS (type) || !COMPLEX_FLOAT_TYPE_P (type))) (non_lvalue @0))) etc. which would be great if it could use frange. Though, I think we also = run here into the problem that match.pd right now avoids the ranger because it could reliably only allow walks from uses to SSA_NAME_DEF_STMTs and not the other direction. But of course those few simplifications are simple enough that they could be also repeated somewhere in the e?vrp code. One thing to consider is that at runtime, not all arithmetics might be as precise as what mpfr does at compile time, so in some cases it should expec= t a few ulps or maybe even more than that as possible errors (especially for library functions). And also take into account different rounding modes if user wants that to be honored. As for exceptions, I guess one thing is that ranger computes ranges and ano= ther thing is that optimization based on that will sometimes need to punt if it could optimize away visible side-effects the user cares about.=