We have functions to query things like whether a real is nonnegative and whether it is integer-valued. At the moment we recurse through SSA name definitions, limited by --param max-ssa-name-query-depth, but it would be better to record this information alongside the SSA name, as range_info_def does for integers.
I think I might have filed about this before.
If we are generalizing VRP, how about vectors? A single interval per vector would be enough for most of the benefit.
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.
Author: rsandifo Date: Tue Oct 27 11:52:54 2015 New Revision: 229423 URL: https://gcc.gnu.org/viewcvs?rev=229423&root=gcc&view=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 24021 really.
(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.
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.
(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.
The master branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>: https://gcc.gnu.org/g:10d6109fe183d984a0377a7afe2854a0d794ebeb commit r13-2741-g10d6109fe183d984a0377a7afe2854a0d794ebeb Author: Aldy Hernandez <aldyh@redhat.com> 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.
The master branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>: https://gcc.gnu.org/g:822a0823c012b912f0108a4da257cd97cbcdb7a3 commit r13-4125-g822a0823c012b912f0108a4da257cd97cbcdb7a3 Author: Aldy Hernandez <aldyh@redhat.com> 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.
fixed