[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Aldy Hernandez --- fixed
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 --- Comment #10 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:822a0823c012b912f0108a4da257cd97cbcdb7a3 commit r13-4125-g822a0823c012b912f0108a4da257cd97cbcdb7a3 Author: Aldy Hernandez Date: Sat Nov 12 11:58:07 2022 +0100 [PR68097] Try to avoid recursing for floats in gimple_stmt_nonnegative_warnv_p. It irks me that a PR named "we should track ranges for floating-point hasn't been closed in this release. This is an attempt to do just that. As mentioned in the PR, even though we track ranges for floats, it has been suggested that avoiding recursing through SSA defs in gimple_assign_nonnegative_warnv_p is also a goal. This patch uses a global range query (no on-demand lookups, just global ranges and minimal folding) to determine if the range of a statement is known to be non-negative. PR tree-optimization/68097 gcc/ChangeLog: * gimple-fold.cc (gimple_stmt_nonnegative_warnv_p): Call range_of_stmt for floats.
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 Bug 68097 depends on bug 24021, which changed state. Bug 24021 Summary: VRP does not work with floating points https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 --- Comment #9 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:10d6109fe183d984a0377a7afe2854a0d794ebeb commit r13-2741-g10d6109fe183d984a0377a7afe2854a0d794ebeb Author: Aldy Hernandez Date: Mon Sep 19 09:59:01 2022 +0200 frange::set_nonnegative should not contain -NAN. A specifically nonnegative range should not contain -NAN, otherwise signbit_p() would return false, because we'd be unsure of the sign. PR 68097/tree-optimization gcc/ChangeLog: * value-range.cc (frange::set_nonnegative): Set +NAN. (range_tests_signed_zeros): New test. * value-range.h (frange::update_nan): New overload to set NAN sign.
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097
--- Comment #8 from Aldy Hernandez ---
(In reply to Richard Biener from comment #7)
> Yes, I think fixed in that we can now record info on FP SSA names. There
> are other bugs for specific things.
>
> What's not fixed is that we still recurse to SSA defs in
> gimple_assign_nonnegative_warnv_p and friends. We might think to fix that
> now,
I see. If I understand things correctly, you may want to do something like:
if (frange::supports_p (TREE_TYPE (name)))
{
frange r;
bool sign;
if (get_global_range_query ()->range_of_expr (r, name)
&& r.signbit_p (sign))
return sign == false;
}
That is, get the global range of the SSA name, and if it has a known signbit,
you should be able to determine if it's nonnegative. The above works correctly
for signed zeros now too.
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 Richard Biener changed: What|Removed |Added Keywords||compile-time-hog --- Comment #7 from Richard Biener --- Yes, I think fixed in that we can now record info on FP SSA names. There are other bugs for specific things. What's not fixed is that we still recurse to SSA defs in gimple_assign_nonnegative_warnv_p and friends. We might think to fix that now, so I'm leaving this bug open for this particular issue, it's a good thing to try for GCC 13.
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #6 from Aldy Hernandez --- (In reply to Richard Biener from comment #3) > Confirmed. > > Note the main part will be to make the FP "range info" available on SSA > names. > > Other useful queries would include "cannot be Inf/NaN/signed zero". > > Note that transforms based on this (and also nonnegative!) need to be careful > as there are no data dependences on conditions. Thus with > > if (x > 0.) >foo (x); > > we may not optimize foo based on 'nonnegative' as code motion has no barrier > that prevents it from hoisting it before the if. > > Yes, vectors could also be handled (and yes, please one "value range" per > SSA name only). Likewise complex (integer) types. Is this PR already solved? FP range info is available on SSA names currently. We can also query inf/NAN/signed zeros/etc. And regarding PR24021 which pinskia mentioned, there is support for VRP-FP now. We just don't understand the PLUS_EXPR. I have a patch for that as well, and should contribute it early next week.
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 Andrew Pinski changed: What|Removed |Added Depends on||24021 --- Comment #5 from Andrew Pinski --- Bug 24021 really. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021 [Bug 24021] VRP does not work with floating points
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 --- Comment #4 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue Oct 27 11:52:54 2015 New Revision: 229423 URL: https://gcc.gnu.org/viewcvs?rev=229423=gcc=rev Log: Move signbit folds to match.pd Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabi. gcc/ * builtins.c (fold_builtin_signbit): Delete. (fold_builtin_2): Handle constant signbit arguments here. * match.pd: Add rules previously handled by fold_builtin_signbit. gcc/testsuite/ PR tree-optimization/68097 * gcc.dg/torture/builtin-nonneg-1.c: Skip at -O0. Add --param max-ssa-name-query-depth=3 to dg-options. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/builtin-nonneg-1.c
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-26 CC||rguenth at gcc dot gnu.org Version|unknown |6.0 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Confirmed. Note the main part will be to make the FP "range info" available on SSA names. Other useful queries would include "cannot be Inf/NaN/signed zero". Note that transforms based on this (and also nonnegative!) need to be careful as there are no data dependences on conditions. Thus with if (x > 0.) foo (x); we may not optimize foo based on 'nonnegative' as code motion has no barrier that prevents it from hoisting it before the if. Yes, vectors could also be handled (and yes, please one "value range" per SSA name only). Likewise complex (integer) types.
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 --- Comment #2 from Marc Glisse --- If we are generalizing VRP, how about vectors? A single interval per vector would be enough for most of the benefit.
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 --- Comment #1 from Andrew Pinski --- I think I might have filed about this before.
