aboutsummaryrefslogtreecommitdiff
path: root/gcc/value-range.cc
AgeCommit message (Collapse)AuthorFilesLines
2022-11-08Provide normalized and denormal format version of real_isdenormal.Aldy Hernandez1-2/+3
Implement a variant of real_isdenormal() to be used within real.cc where the argument is known to be in denormal format. Rewrite real_isdenormal() for use outside of real.cc where the argument is known to be normalized. gcc/ChangeLog: * real.cc (real_isdenormal): New. (encode_ieee_single): Call real_isdenormal. (encode_ieee_double): Same. (encode_ieee_extended): Same. (encode_ieee_quad): Same. (encode_ieee_half): Same. (encode_arm_bfloat_half): Same. * real.h (real_isdenormal): Add mode argument. Rewrite for normalized values. * value-range.cc (frange::flush_denormals_to_zero): Pass mode to real_isdenormal.
2022-11-02Fix bug in frange::contains_p() for signed zeros.Aldy Hernandez1-1/+9
The contains_p() code wasn't returning true for non-singleton ranges containing signed zeros. With this patch we now handle: -0.0 exists in [-3, +5.0] +0.0 exists in [-3, +5.0] gcc/ChangeLog: * value-range.cc (frange::contains_p): Fix signed zero handling. (range_tests_signed_zeros): New test.
2022-11-01Intersect with nonzero bits can indicate change incorrectly.Andrew MacLeod1-0/+4
* value-range.cc (irange::intersect_nonzero_bits): If new non-zero mask is the same as original, flag no change.
2022-10-28Change remaining flag_finite_math_only use in value-range.cc.Aldy Hernandez1-1/+1
gcc/ChangeLog: * value-range.cc (range_tests_floats): Use HONOR_INFINITIES.
2022-10-26Convert flag_finite_math_only uses in frange to HONOR_*.Aldy Hernandez1-3/+3
As mentioned earlier, we should be using HONOR_* on types rather than flag_finite_math_only. gcc/ChangeLog: * value-range.cc (frange::set): Use HONOR_*. (frange::verify_range): Same. * value-range.h (frange_val_min): Same. (frange_val_max): Same.
2022-10-24Check HONOR_NANS instead of flag_finite_math_only in frange:verify_range.Aldy Hernandez1-8/+25
[Jakub and other FP experts, would this be OK, or am I missing something?] Vax does not seem to have !flag_finite_math_only, but float_type_node does not HONOR_NANS. The check in frange::verify_range dependend on flag_finite_math_only, which is technically not correct since frange::set_varying() checks HONOR_NANS instead of flag_finite_math_only. I'm actually getting tired of flag_finite_math_only and !flag_finite_math_only discrepancies in the selftests (Vax and rx-elf come to mind). I think we should just test both alternatives in the selftests as in this patch. We could also check flag_finite_math_only=0 with a float_type_node that does not HONOR_NANs, but I have no idea how to twiddle FLOAT_MODE_FORMAT temporarily, and that may be over thinking it. PR tree-optimization/107365 gcc/ChangeLog: * value-range.cc (frange::verify_range): Predicate NAN check in VARYING range on HONOR_NANS instead of flag_finite_math_only. (range_tests_floats): Same. (range_tests_floats_various): New. (range_tests): Call range_tests_floats_various.
2022-10-22Update selftest such that [-Inf, +Inf] is always VARYING for -ffinite-math-only.Aldy Hernandez1-2/+5
[-Inf, +Inf] +-NAN gets normalized as VARYING. There is a test that drops the NAN possibility, and tests that the range is no longer VARYING but [-Inf, +Inf]. However, for -ffinite-math-only targets (Vax, RX, etc) the range would still be VARYING because the VARYING range never had a NAN to begin with. This fixes the test. I have a precommit hook that does self-tests with -fno-finite-math-only, -ffinite-math-only, and -ffast-math as a sanity check, but my precommit hook last week was disabled because there was a tree-ssa.exp in mainline failing which was throwing off my scripts. My apologies. gcc/ChangeLog: * value-range.cc (range_tests_floats): Predicate [-Inf, +Inf] test with !flag_finite_math_only.
2022-10-20Do not set NAN flags for VARYING ranges when !HONOR_NANS.Aldy Hernandez1-3/+8
Since NANs can't appear in ranges for !HONOR_NANS, there's no reason to set them in a VARYING range. gcc/ChangeLog: * value-range.h (frange::set_varying): Do not set NAN flags for !HONOR_NANS. * value-range.cc (frange::normalize_kind): Adjust for no NAN when !HONOR_NANS. (frange::verify_range): Same. * range-op-float.cc (maybe_isnan): Remove flag_finite_math_only check.
2022-10-19[PR tree-optimization/107312] Make range_true_and_false work with 1-bit ↵Aldy Hernandez1-0/+2
signed types. range_true_and_false() returns a range of [0,1], which for a 1-bit signed integer gets passed to the irange setter as [0, -1]. These endpoints are out of order and cause an ICE. Through some dumb luck, the legacy code swaps out of order endpoints, because old VRP would sometimes pass endpoints reversed, depending on the setter to fix them. This swapping does not happen for non-legacy, hence the ICE. The right thing to do (apart from killing legacy and 1-bit signed integers ;-)), is to avoid passing out of order endpoints for 1-bit signed integers. For that matter, a range of [-1, 0] (signed) or [0, 1] (unsigned) is just varying. PR tree-optimization/107312 gcc/ChangeLog: * range.h (range_true_and_false): Special case 1-bit signed types. * value-range.cc (range_tests_misc): New test. gcc/testsuite/ChangeLog: * gcc.target/i386/pr107312.c: New test.
2022-10-17Do not test for -Inf when flag_finite_math_only.Aldy Hernandez1-4/+7
PR tree-optimization/107286 gcc/ChangeLog: * value-range.cc (range_tests_floats): Do not test for -Inf when flag_finite_math_only.
2022-10-14Implement distinction between HONOR_SIGNED_ZEROS and MODE_HAS_SIGNED_ZEROS.Aldy Hernandez1-1/+8
gcc/ChangeLog: * value-range.cc (frange::set): Implement distinction between HONOR_SIGNED_ZEROS and MODE_HAS_SIGNED_ZEROS.
2022-10-14Check rvc_normal in real_isdenormal.Aldy Hernandez1-0/+5
[-Inf, -Inf] is being flushed to [-Inf, -0.0] because real_isdenormal is being overly pessimistic. It is missing a check for rvc_normal. This doesn't cause problems in real.cc because all uses of real_isdenormal are already on the rvc_normal path. The uses in value-range.cc however, are not. This patch adds a check for rvc_normal. gcc/ChangeLog: * real.h (real_isdenormal): Check rvc_normal. * value-range.cc (range_tests_floats): New test.
2022-10-14Normalize ranges over the range for both bounds when -ffinite-math-only.Aldy Hernandez1-0/+4
[-Inf, +Inf] was being chopped correctly for -ffinite-math-only, but [-Inf, -Inf] was not. This was latent because a bug in real_isdenormal is causing us to flush -Inf to zero. gcc/ChangeLog: * value-range.cc (frange::set): Normalize ranges for both bounds.
2022-10-14Drop -0.0 in frange::set() for !HONOR_SIGNED_ZEROS.Aldy Hernandez1-0/+8
Similar to what we do for NANs when !HONOR_NANS and Inf when flag_finite_math_only, we can remove -0.0 from the range at creation time. We were kinda sorta doing this because there is a bug in real_isdenormal that is causing flush_denormals_to_zero to saturate [x, -0.0] to [x, +0.0] when !HONOR_SIGNED_ZEROS. Fixing this bug (upcoming), causes us to leave -0.0 in places where we aren't expecting it (the intersection code). gcc/ChangeLog: * value-range.cc (frange::set): Drop -0.0 for !HONOR_SIGNED_ZEROS.
2022-10-12Disable tree to bool conversion in frange::update_nan.Aldy Hernandez1-1/+1
We have a set_nan(type) method which can be confused with update_nan(bool) because of the silent conversion of pointers to bool. Currently, if you call update_nan(tree), you'll set the possibility of NAN with a sign of true if tree is non-null. This is prone to error and this patch disallows this behavior. gcc/ChangeLog: * value-range.cc (frange::set_nonnegative): Pass bool to update_nan. * value-range.h: Disallow conversion to bool in update_nan().
2022-10-11[PR107195] Set range to zero when nonzero mask is 0.Aldy Hernandez1-0/+5
When solving 0 = _15 & 1, we calculate _15 as: [irange] int [-INF, -2][0, +INF] NONZERO 0xfffffffe The known value of _15 is [0, 1] NONZERO 0x1 which is intersected with the above, yielding: [0, 1] NONZERO 0x0 This eventually gets copied to a _Bool [0, 1] NONZERO 0x0. This is problematic because here we have a bool which is zero, but returns false for irange::zero_p, since the latter does not look at nonzero bits. This causes logical_combine to assume the range is not-zero, and all hell breaks loose. I think we should just normalize a nonzero mask of 0 to [0, 0] at creation, thus avoiding all this. PR tree-optimization/107195 gcc/ChangeLog: * value-range.cc (irange::set_range_from_nonzero_bits): Set range to [0,0] when nonzero mask is 0. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr107195-1.c: New test. * gcc.dg/tree-ssa/pr107195-2.c: New test.
2022-10-07gcc: Fix comment typoJonathan Wakely1-1/+1
gcc/ChangeLog: * value-range.cc (irange::irange_contains_p): Fix comment typo.
2022-10-07Convert nonzero mask back to tree.Aldy Hernandez1-19/+66
Having nonzero masks always set had a performance penalty of 10% in VRP, so mask==NULL is a shortcut to all bits set. gcc/ChangeLog: * value-range.cc (irange::irange_set): Convert nonzero mask to tree. (irange::irange_set_anti_range): Same. (irange::set): Same. (irange::verify_range): Same. (irange::contains_p): Same. (irange::invert): Same. (irange::set_range_from_nonzero_bits): Same. (irange::set_nonzero_bits): Same. (mask_to_wi): Same. (irange::intersect_nonzero_bits): Same. (irange::union_nonzero_bits): Same. * value-range.h (irange::varying_compatible_p): Same. (gt_ggc_mx): Same. (gt_pch_nx): Same. (irange::set_undefined): Same. (irange::set_varying): Same.
2022-10-07Fix comment typosJakub Jelinek1-1/+1
When looking at tree-inline.cc I've noticed a comment typo and grepped for similar typos elsewhere. 2022-10-07 Jakub Jelinek <jakub@redhat.com> * ipa-prop.h (ipa_constant_data): Fix comment typo. * value-range.cc (irange::irange_contains_p): Likewise. * value-relation.cc (dom_oracle::set_one_relation): Likewise. * gimple-predicate-analysis.cc (predicate::simplify_4): Likewise. * tree-inline.cc (remap_ssa_name): Likewise.
2022-10-06Setting explicit NANs sets UNDEFINED for -ffinite-math-only.Aldy Hernandez1-30/+29
We recently agreed that setting a range of NAN should instead set UNDEFINED for -ffinite-math-only. This patch makes that change to frange::set_nan() directly. Also, calling frange::update_nan() will now be a nop for !HONOR_NANS. Doing this in the setters simplifies everywhere we set NANs, as it keeps us from introducing NANs by mistake. gcc/ChangeLog: * value-range.cc (frange::set): Call set_nan unconditionally. (range_tests_nan): Adjust tests. (range_tests_signed_zeros): Same. (range_tests_floats): Same. * value-range.h (frange::update_nan): Guard with HONOR_NANS. (frange::set_nan): Set undefined if !HONOR_NANS.
2022-10-04Remove assert from set_nonzero_bits.Aldy Hernandez1-1/+0
The assert removed by this patch was there to keep users from passing masks of incompatible types. The self tests are passing host wide ints down (set_nonzero_bits (-1)), which seem to be 32 bits, whereas some embedded targets have integer_type_node's of 16-bits. This is causing problems in m32c-elf, among others. I suppose there's no harm in passing a 32-bit mask, because set_nonzero_bits calls wide_int::from() to convert the mask to the appropriate type. So we can remove the assert. gcc/ChangeLog: * value-range.cc (irange::set_nonzero_bits): Remove assert.
2022-10-04Convert nonzero mask in irange to wide_int.Aldy Hernandez1-152/+118
The reason the nonzero mask was kept in a tree was basically inertia, as everything in irange is a tree. However, there's no need to keep it in a tree, as the conversions to and from wide ints are very annoying. That, plus special casing NULL masks to be -1 is prone to error. I have not only rewritten all the uses to assume a wide int, but have corrected a few places where we weren't propagating the masks, or rather pessimizing them to -1. This will become more important in upcoming patches where we make better use of the masks. Performance testing shows a trivial improvement in VRP, as things like irange::contains_p() are tied to a tree. Ughh, can't wait for trees in iranges to go away. gcc/ChangeLog: * value-range-storage.cc (irange_storage_slot::set_irange): Remove special case. * value-range.cc (irange::irange_set): Adjust for nonzero mask being a wide int. (irange::irange_set_anti_range): Same. (irange::set): Same. (irange::verify_range): Same. (irange::legacy_equal_p): Same. (irange::operator==): Same. (irange::contains_p): Same. (irange::legacy_intersect): Same. (irange::legacy_union): Same. (irange::irange_single_pair_union): Call union_nonzero_bits. (irange::irange_union): Same. (irange::irange_intersect): Call intersect_nonzero_bits. (irange::intersect): Adjust for nonzero mask being a wide int. (irange::invert): Same. (irange::set_nonzero_bits): Same. (irange::get_nonzero_bits_from_range): New. (irange::set_range_from_nonzero_bits): New. (irange::get_nonzero_bits): Adjust for nonzero mask being a wide int. (irange::intersect_nonzero_bits): Same. (irange::union_nonzero_bits): Same. (range_tests_nonzero_bits): Remove test. * value-range.h (irange::varying_compatible_p): Adjust for nonzero mask being a wide int. (gt_ggc_mx): Same. (gt_pch_nx): Same. (irange::set_undefined): Same. (irange::set_varying): Same. (irange::normalize_kind): Same.
2022-10-03Do not pessimize range in set_nonzero_bits.Aldy Hernandez1-0/+13
Currently if we have a range of [0,0] and we set the nonzero bits to 1, the current code pessimizes the range to [0,1] because it assumes the range is [1,1] plus the possibility of 0. This fixes the oversight. gcc/ChangeLog: * value-range.cc (irange::set_nonzero_bits): Do not pessimize range. (range_tests_nonzero_bits): New test.
2022-10-03Avoid comparing ranges when sub-ranges is 0.Aldy Hernandez1-0/+3
There is nothing else to compare when the number of sub-ranges is 0. gcc/ChangeLog: * value-range.cc (irange::operator==): Early bail on m_num_ranges equal to 0.
2022-10-03Do not compare nonzero masks for varying.Aldy Hernandez1-4/+1
There is no need to compare nonzero masks when comparing two VARYING ranges, as they are always the same when range types are the same. gcc/ChangeLog: * value-range.cc (irange::legacy_equal_p): Remove nonozero mask check when comparing VR_VARYING ranges.
2022-09-27irange: keep better track of powers of 2.Aldy Hernandez1-0/+13
When setting the nonzero bits to a mask containing only one bit, set the range immediately, as it can be devined from the mask. This helps us keep better track of powers of two. For example, with this patch a nonzero mask of 0x8000 is set to a range of [0,0][0x8000,0x8000] with a nonzero mask of 0x8000. gcc/ChangeLog: * value-range.cc (irange::set_nonzero_bits): Set range when known. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/popcount6.c: New test.
2022-09-26ranger: remove unused functionMartin Liska1-9/+0
gcc/ChangeLog: * value-range.cc (tree_compare): Remove unused function.
2022-09-23frange: Make the setter taking trees a wrapper.Aldy Hernandez1-17/+14
The frange setter does all its work in trees. This incurs a penalty for the real_value variants because they must wrap their arguments into a tree and pass it to the tree setter, which will then do the opposite. This is leftovers from the irange setter. Even though the we still need constructors taking trees so we can interact with the tree world, there's no sense penalizing the rest of the implementation. Tested on x86-64 Linux. gcc/ChangeLog: * value-range.cc (frange::set): Swap setters such that the one accepting REAL_VALUE_TYPE does all the work.
2022-09-23frange: drop endpoints to min/max representable numbers for -ffinite-math-only.Aldy Hernandez1-25/+21
Similarly to how we drop NANs to UNDEFINED when -ffinite-math-only, I think we can drop the numbers outside of the min/max representable numbers to the representable number. This means the endpoings to VR_VARYING for -ffinite-math-only can now be the min/max representable, instead of -INF and +INF. Saturating in the setter means that the upcoming implementation for binary operators no longer have to worry about doing the right thing for -ffinite-math-only. If the range goes outside the limits, it'll get chopped down. Tested on x86-64 Linux. gcc/ChangeLog: * range-op-float.cc (build_le): Use vrp_val_*. (build_lt): Same. (build_ge): Same. (build_gt): Same. * value-range.cc (frange::set): Chop ranges outside of the representable numbers for -ffinite-math-only. (frange::normalize_kind): Use vrp_val*. (frange::verify_range): Same. (frange::set_nonnegative): Same. (range_tests_floats): Remove tests that depend on -INF and +INF. * value-range.h (real_max_representable): Add prototype. (real_min_representable): Same. (vrp_val_max): Set max representable number for -ffinite-math-only. (vrp_val_min): Same but for min. (frange::set_varying): Use vrp_val*.
2022-09-21[PR106967] Set known NANs to undefined for flag_finite_math_only.Aldy Hernandez1-2/+7
Explicit NANs in the IL can be treated as undefined for flag_finite_math_only. This causes all the right things to happen wrt threading, folding, etc. It also saves us special casing throughout. PR tree-optimization/106967 gcc/ChangeLog: * value-range.cc (frange::set): Set known NANs to undefined for flag_finite_math_only.
2022-09-21Clear unused flags in frange for undefined ranges.Aldy Hernandez1-4/+4
gcc/ChangeLog: * value-range.cc (frange::combine_zeros): Call set_undefined. (frange::intersect_nans): Same. (frange::intersect): Same. (frange::verify_range): Undefined ranges do not have a type. * value-range.h (frange::set_undefined): Clear NAN flags and type.
2022-09-20frange::set_nonnegative should not contain -NAN.Aldy Hernandez1-0/+9
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.
2022-09-20frange: flush denormals to zeroAldy Hernandez1-0/+23
For some architectures (or for -funsafe-math-optimizations) we may flush denormals to zero, in which case we need to be careful to extend the ranges to the appropriate zero. This patch does exactly that. For a range of [x, -DENORMAL] we flush to [x, -0.0] and for [+DENORMAL, x] we flush to [+0.0, x]. gcc/ChangeLog: * value-range.cc (frange::flush_denormals_to_zero): New. (frange::set): Call flush_denormals_to_zero. * value-range.h (class frange): Add flush_denormals_to_zero.
2022-09-18[PR106831] Avoid propagating long doubles that may have multiple ↵Jakub Jelinek1-0/+15
representations. Long doubles are tricky when it comes to considering singletons because small numbers and +-INF can have multiple representations for the same number. So we need to be very careful not to treat those as singletons, lest they be incorrectly propagated by VRP. This is similar to the -0.0 and +0.0 duality. In long doubles +INF can be represented with +INF in the MSB and either -0.0 or +0.0 in the LSB. Similarly for numbers that are exactly representable in DF. For example, 1.0 can be represented as either (1.0, +0.0) or (1.0, -0.0). This patch avoids treating these numbers as singletons. Note that NANs in long double format have a LSB of don't care, but this is irrelevant for singleton_p, because NANs are never considered singletons. Also, internally in the frange we store NANs as a pair of boolean flags indicating whether they are +NAN or -NAN, so we don't need any special treatment here for comparing range equality etc. We never see anything but the boolean flags. PR middle-end/106831 gcc/ChangeLog: * value-range.cc (frange::singleton_p): Avoid propagating long doubles that may have multiple representations.
2022-09-18Rewrite NAN and sign handling in frangeAldy Hernandez1-299/+322
The attatched patch rewrites the NAN and sign handling, dropping both tristates in favor of a pair of boolean flags for NANs, and nothing at all for signs. The signs are tracked in the range itself, so now it's possible to describe things like [-0.0, +0.0] +NAN, [+0, +0], [-5, +0], [+0, 3] -NAN, etc. Here is an example of the various ranges and how they are displayed: [frange] float VARYING NAN ;; Varying includes NAN [frange] UNDEFINED ;; Empty set as always [frange] float [] +-NAN ;; Unknown sign NAN [frange] float [] -NAN ;; -NAN [frange] float [] +NAN ;; +NAN [frange] float [-0.0, 0.0] ;; All zeros. [frange] float [-0.0, -0.0] +-NAN ;; -0 or NAN. [frange] float [-5.0e+0, -1.0e+0] +NAN ;; [-5, -1] or +NAN [frange] float [-5.0e+0, -0.0] +-NAN ;; [-5, -0] or NAN [frange] float [-5.0e+0, -0.0] ;; [-5, -0] [frange] float [5.0e+0, 1.0e+1] ;; [5, 10] Notice the NAN signs are decoupled from the range, so we can represent a negative range with a positive NAN. For this range, frange::signbit_p() would return false, as only when the signs of the NANs and range agree can we be certain. There is no longer any pessimization of ranges for intersects involving NANs. Also, union and intersect work with signed zeros: // [-0, x] U [+0, x] => [-0, x] // [ x, -0] U [ x, +0] => [ x, +0] // [-0, x] ^ [+0, x] => [+0, x] // [ x, -0] ^ [ x, +0] => [ x, -0] The special casing for signed zeros in the singleton code is gone in favor of just making sure the signs in the range agree, that is [-0, -0] for example. I have removed the idea that a known NAN is a "range", so a NAN is no longer in the endpoints itself. Requesting the bound of a known NAN is a hard fail. For that matter, we don't store the actual NAN in the range. The only information we have are the set of boolean flags. This way we make sure nothing seeps into the frange. This also means it's explicit that we don't track anything but the sign in NANs. We can revisit this if we desire to track signalling or whatever concoction y'all can imagine. Regstrapped with mpfr tests on x86-64 and ppc64le Linux. Selftests were also run with -ffinite-math-only on x86-64. At Jakub's suggestion, I built lapack with associated tests. They pass on x86-64 and ppc64le Linux with no regressions from mainline. As a sanity check, I also ran them for -ffinite-math-only on x86 which (as expected) returned: NaN arithmetic did not perform per the ieee spec Otherwise, all tests pass for -ffinite-math-only. gcc/ChangeLog: * range-op-float.cc (frange_add_zeros): Replace set_signbit with union of zero. * value-query.cc (range_query::get_tree_range): Remove set_signbit use. * value-range-pretty-print.cc (vrange_printer::print_frange_prop): Remove. (vrange_printer::print_frange_nan): New. * value-range-pretty-print.h (print_frange_prop): Remove. (print_frange_nan): New. * value-range-storage.cc (frange_storage_slot::set_frange): Set kind and NAN fields. (frange_storage_slot::get_frange): Restore kind and NAN fields. * value-range-storage.h (class frange_storage_slot): Add kind and NAN fields. * value-range.cc (frange::update_nan): Remove. (frange::set_signbit): Remove. (frange::set): Adjust for NAN fields. (frange::normalize_kind): Remove m_props. (frange::combine_zeros): New. (frange::union_nans): New. (frange::union_): Handle new NAN fields. (frange::intersect_nans): New. (frange::intersect): Handle new NAN fields. (frange::operator=): Same. (frange::operator==): Same. (frange::contains_p): Same. (frange::singleton_p): Remove special case for signed zeros. (frange::verify_range): Adjust for new NAN fields. (frange::set_zero): Handle signed zeros. (frange::set_nonnegative): Same. (range_tests_nan): Adjust tests. (range_tests_signed_zeros): Same. (range_tests_signbit): Same. (range_tests_floats): Same. * value-range.h (class fp_prop): Remove. (FP_PROP_ACCESSOR): Remove. (class frange_props): Remove (frange::lower_bound): NANs don't have endpoints. (frange::upper_bound): Same. (frange_props::operator==): Remove. (frange_props::union_): Remove. (frange_props::intersect): Remove. (frange::update_nan): New. (frange::clear_nan): New. (frange::undefined_p): New. (frange::set_nan): New. (frange::known_finite): Adjust for new NAN representation. (frange::maybe_isnan): Same. (frange::known_isnan): Same. (frange::signbit_p): Same. * gimple-range-fold.cc (range_of_builtin_int_call): Rename known_signbit_p into signbit_p.
2022-09-14Use frange::set_nan() from the generic frange::set().Aldy Hernandez1-13/+14
This patch cleans up the frange::set() code by passing all things NAN to frange::set_nan(). No functional changes. Regstrapped on x86-64 Linux, plus I ran selftests for -ffinite-math-only. gcc/ChangeLog: * value-range.cc (frange::set): Use set_nan. * value-range.h (frange::set_nan): Inline code originally in set().
2022-09-14Provide cleaner set_nan(), clear_nan(), and update_nan() methods.Aldy Hernandez1-26/+26
set_* has a very specific meaning for irange's and friends. Methods prefixed with set_* are setters clobbering the existing range. As such, the current set_nan() method is confusing in that it's not actually setting a range to a NAN, but twiddling the NAN flags for an existing frange. This patch replaces set_nan() with an update_nan() to set the flag, and clear_nan() to clear it. This makes the code clearer, and though the confusing tristate is still there, it will be removed in upcoming patches. Also, there is now an actual set_nan() method to set the range to a NAN. This replaces two out of class functions doing the same thing. In future patches I will also add the ability to create a NAN with a specific sign, but doing so now would be confusing because we're not tracking NAN signs. We should also submit set_signbit to the same fate, but it's about to get removed. No functional changes. Regstrapped on x86-64 Linux, plus I ran selftests for -ffinite-math-only. gcc/ChangeLog: * range-op-float.cc (frange_set_nan): Remove. (build_lt): Use set_nan, update_nan, clear_nan. (build_gt): Same. (foperator_equal::op1_range): Same. (foperator_not_equal::op1_range): Same. (foperator_lt::op1_range): Same. (foperator_lt::op2_range): Same. (foperator_le::op1_range): Same. (foperator_le::op2_range): Same. (foperator_gt::op1_range): Same. (foperator_gt::op2_range): Same. (foperator_ge::op1_range): Same. (foperator_ge::op2_range): Same. (foperator_unordered::op1_range): Same. (foperator_ordered::op1_range): Same. * value-query.cc (range_query::get_tree_range): Same. * value-range.cc (frange::set_nan): Same. (frange::update_nan): Same. (frange::union_): Same. (frange::intersect): Same. (range_tests_nan): Same. (range_tests_signed_zeros): Same. (range_tests_signbit): Same. (range_tests_floats): Same. * value-range.h (class frange): Add update_nan and clear_nan. (frange::set_nan): New.
2022-09-14Minor fixes to frange.Aldy Hernandez1-10/+5
Following are a series of cleanups to the frange code in preparation for a much more invasive patch rewriting the NAN and sign tracking bits. Please be patient, as I'm trying to break everything up into small chunks instead of dropping a mondo patch removing the NAN and sign tristate handling. No functional changes. Regstrapped on x86-64 Linux, plus I ran selftests for -ffinite-math-only. gcc/ChangeLog: * value-query.cc (range_query::get_tree_range): Remove check for overflow. * value-range-pretty-print.cc (vrange_printer::visit): Move read of type until after undefined_p is checked. * value-range.cc (frange::set): Remove asserts for REAL_CST. (frange::contains_p): Tidy up. (range_tests_nan): Add comment. * value-range.h (frange::type): Check for undefined_p. (frange::set_undefined): Remove set of endpoints.
2022-09-12frange::set_signbit: Avoid changing sign when already in the correct sign.Aldy Hernandez1-2/+6
We should avoid pessimizing the signbit when it's already correct. In this particular case we were trying to change the signbit to "unknown", when it was obviously negative. This test is actually slated for removal with my upcoming revamp of the signbit and NAN tracking, per the conversations regarding tristate. The signbit will be removed in favor of keeping track of it in the range itself, and NAN will just be a pair of boolean flags. However, I don't plan to disturb the tree until after Cauldron. Tested on x86-64 Linux including mpfr tests. Also tested selftests with -ffinite-math-only on x86-64 as well as on a cross to pdp11-aout. gcc/ChangeLog: * value-range.cc (frange::set_signbit): Avoid changing sign when already in the correct sign.
2022-09-08Implement known/maybe fpclassify like API for frange.Aldy Hernandez1-53/+73
gcc/ChangeLog: * gimple-range-fold.cc (fold_using_range::range_of_builtin_int_call): Use fpclassify like API. * range-op-float.cc (finite_operand_p): Same. (finite_operands_p): Same. (foperator_lt::fold_range): Same. (foperator_le::fold_range): Same. (foperator_gt::fold_range): Same. (foperator_ge::fold_range): Same. (foperator_unordered::fold_range): Same. (foperator_unordered::op1_range): Same. (foperator_ordered::fold_range): Same. * value-range.cc (frange::set_nan): Same. (frange::set_signbit): Same. (frange::union_): Same. (frange::intersect): Same. (frange::operator==): Same. (frange::singleton_p): Same. (frange::verify_range): Same. (range_tests_nan): Same. (range_tests_floats): Same. * value-range.h(frange::known_finite): New. (frange::maybe_inf): New. (frange::known_inf): New. (frange::maybe_nan): New. (frange::known_nan): New. (frange::known_signbit): New.
2022-09-05Do not ICE when updating a NAN to a non-NAN.Aldy Hernandez1-2/+10
Updating a definite NAN to a definitely not NAN was an assertion failure, but it turns out we can have such a scenario while attempting to thread an impossible path. This patch updates the range to undefined. What happens in the testcase is that we are trying to thread path that starts like this: <bb 5> [local count: 81335936906]: SR.30_3 = Nan; goto <bb 7>; [100.00%] <bb 7> [local count: 108447915740]: # SR.30_25 = PHI <SR.30_3(5), SR.30_12(6)> plus_33 = SR.30_25; w1$value__13 = f_distance$D2421$value__1; w2$value__14 = plus_33; if (w1$value__13 == w2$value__14) goto <bb 8>; [50.00%] else goto <bb 9>; [50.00%] On the path, SR.30_25 is NAN, which ultimately makes w2$value__14 a NAN. This means that the 7->8 is impossible on the path. On the true arm (foperator_equal::op1_range) we are asserting that op1 (w1$value__13) is a !NAN because for the == conditional to succeed, neither operand can be a NAN. But...we know that operand 2 is a NAN. This is an impossible scenario. We are ICEing because frange::set_nan() sees the NAN and the desire to set the NAN flag to NO. The correct thing to do is to set the range to undefined, which is basically unreachable, and will cause all the right things to happen. For that matter, the threader will see that an UNDEFINED range was calculated in the path and abort trying to investigate paths in that direction. PR middle-end/106824 gcc/ChangeLog: * value-range.cc (frange::set_nan): Set undefined when updating a NAN to a non-NAN. gcc/testsuite/ChangeLog: * g++.dg/pr106824.C: New test.
2022-09-05Be even more conservative in intersection of NANs.Aldy Hernandez1-19/+16
Intersecting two ranges where one is a NAN is keeping the sign bit of the NAN range. This is not correct as the sign bits may not match. I think the only time we're absolutely sure about the intersection of a NAN and something else, is when both are a NAN with exactly the same properties (sign bit). If we're intersecting two NANs of differing sign, we can decide later whether that's undefined or just a NAN with no known sign. For now I've done the latter. I'm still mentally working on intersections involving NANs, especially if we want to keep track of signbits. For now, let's be extra careful and only do things we're absolutely sure about. Later we may want to fold the intersect of [NAN,NAN] and say [3,5] with the posibility of NAN, to a NAN, but I'm not 100% sure. As I've said before, setting varying is always a safe choice, because it means we know nothing and ranger won't attempt to optimize anything. gcc/ChangeLog: * value-range.cc (early_nan_resolve): Remove. (frange::intersect): Handle NANs.
2022-09-04Do not clobber signbit when unioning a NAN.Aldy Hernandez1-4/+21
When unioning a known NAN and something else, we're dropping the properties of the NAN, particularly the sign. This fixes the oversight. With this patch, we should be keeping the sign bit up to date, even in the presence of NANs. gcc/ChangeLog: * value-range.cc (frange::union_): Do not drop properties when unioning a NAN with something else. (range_tests_signed_zeros): Add tests.
2022-09-03[PR/middle-end 106819] NANs can never be a singletonAldy Hernandez1-5/+4
Possible NANs can never be a singleton, so they will never be propagated. This was the intent, and then the signed zero code crept in, and was mistakenly checked before the NAN. PR/middle-end 106819 gcc/ChangeLog: * value-range.cc (frange::singleton_p): Move NAN check to the top. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr106819.c: New test.
2022-09-01Convert ranger uses of real_inf to dconst[n]inf.Aldy Hernandez1-15/+8
gcc/ChangeLog: * range-op-float.cc (build_le): Convert to dconst*inf. (build_ge): Same. * value-range.cc (frange::set_signbit): Same. (frange::normalize_kind): Same. (range_tests_floats): Same. * value-range.h (vrp_val_max): Same. (vrp_val_min): Same. (frange::set_varying): Same.
2022-09-01Add signbit property to frange to better model signed zeros.Aldy Hernandez1-26/+174
As discussed here: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600656.html This adds an frange property to keep track of the sign bit. We keep it updated at all times, but we don't use it make any decisions when !HONOR_SIGNED_ZEROS. With this property we can now query the range for the appropriate sign with frange::get_signbit (). Possible values are yes, no, and unknown. gcc/ChangeLog: * range-op-float.cc (foperator_equal::op1_range): Do not copy sign bit. (foperator_not_equal::op1_range): Same. * value-query.cc (range_query::get_tree_range): Set sign bit. * value-range-pretty-print.cc (vrange_printer::visit): Dump sign bit. * value-range.cc (frange::set_signbit): New. (frange::set): Adjust for sign bit. (frange::normalize_kind): Same. (frange::union_): Remove useless comment. (frange::intersect): Same. (frange::contains_p): Adjust for sign bit. (frange::singleton_p): Same. (frange::verify_range): Same. (range_tests_signbit): New tests. (range_tests_floats): Call range_tests_signbit. * value-range.h (class frange_props): Add signbit (class frange): Same.
2022-09-01Make frange selftests work on !HONOR_NANS systems.Aldy Hernandez1-9/+14
I'm just shuffling the FP self tests here, with no change to existing functionality. If we agree that explicit NANs in the source code with !HONOR_NANS should behave any differently, I'm happy to address whatever needs fixing, but for now I'd like to unblock the !HONOR_NANS build systems. I have added an adaptation of a test Jakub suggested we handle in the PR: void funk(int cond) { float x; if (cond) x = __builtin_nan (""); else x = 1.24; bar(x); } For !HONOR_NANS, the range for the PHI of x_1 is the union of 1.24 and NAN which is really 1.24 with a maybe NAN. This reflects the IL-- the presence of the actual NAN. However, VRP will propagate this because it sees the 1.24 and ignores the possibility of a NAN, per !HONOR_NANS. IMO, this is correct. OTOH, for HONOR_NANS the unknown NAN property keeps us from propagating the value. Is there a reason we don't warn for calls to __builtin_nan when !HONOR_NANS? That makes no sense to me. PR tree-optimization/106785 gcc/ChangeLog: * value-range.cc (range_tests_nan): Adjust tests for !HONOR_NANS. (range_tests_floats): Same. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/vrp-float-nan-1.c: New test.
2022-08-30Improve union of ranges containing NAN.Aldy Hernandez1-10/+34
Previously [5,6] U NAN would just drop to VARYING. With this patch, the resulting range becomes [5,6] with the NAN bit set to unknown. [I still have yet to decide what to do with intersections. ISTM, the intersection of a known NAN with anything else should be a NAN, but it could also be undefined (the empty set). I'll have to run some tests and see. Currently, we drop to VARYING cause well... it's always safe to give up;-).] gcc/ChangeLog: * value-range.cc (early_nan_resolve): Change comment. (frange::union_): Handle union when one side is a NAN. (range_tests_nan): Add tests for NAN union.
2022-08-30Force a [NAN, NAN] range when the definite NAN property is set.Aldy Hernandez1-19/+36
Setting the definite NAN property should also force a [NAN, NAN] range, otherwise we'd have two ways of representing a NAN: with the endpoints or with the property. In the ranger world we avoid at all costs having more than one representation for a range. In doing this, I removed the FRANGE_PROP_ACCESSOR macro, since it looks like setting a property may have repercurssions in the range itself, so it's best for the client to definte its own setter. gcc/ChangeLog: * value-range-storage.cc (frange_storage_slot::get_frange): Use frange_nan. * value-range.cc (frange::set_nan): New. (frange_nan): Move to header file. (range_tests_nan): Adjust frange_nan callers to pass type. New test. * value-range.h (FRANGE_PROP_ACCESSOR): Remove. (frange_nan): New.
2022-08-30Add support for floating point endpoints to frange.Aldy Hernandez1-45/+417
The current implementation of frange is just a type with some bits to represent NAN and INF. We can do better and represent endpoints to ultimately solve longstanding PRs such as PR24021. This patch adds these endpoints. In follow-up patches I will add support for a bare bones PLUS_EXPR range-op-float entry to solve the PR. I have chosen to use REAL_VALUE_TYPEs for the endpoints, since that's what we use underneath the trees. This will be somewhat analogous to our eventual use of wide-ints in the irange. No sense going through added levels of indirection if we can avoid it. That, plus real.* already has a nice API for dealing with floats. With this patch, ranges will be closed float point intervals, which make the implementation simpler, since we don't have to keep track of open/closed intervals. This is conservative enough for use in the ranger world, as we'd rather err on the side of more elements in a range, than less. For example, even though we cannot precisely represent the open interval (3.0, 5.0) with this approach, it is perfectably reasonable to represent it as [3.0, 5.0] since the closed interval is a super set of the open one. In the VRP/ranger world, it is always better to err on the side of more information in a range, than not. After all, when we don't know anything about a range, we just use VARYING which is a fancy term for a range spanning the entire domain. Since REAL_VALUE_TYPEs have properly defined infinity and NAN semantics, all the math can be made to work: [-INF, 3.0] !NAN => Numbers <= 3.0 (NAN cannot happen) [3.0, 3.0] => 3.0 or NAN. [3.0, +INF] => Numbers >= 3.0 (NAN is possible) [-INF, +INF] => VARYING (NAN is possible) [-INF, +INF] !NAN => Entire domain. NAN cannot happen. Also, since REAL_VALUE_TYPEs can represent the minimum and maximum representable values of a TYPE_MODE, we can disambiguate between them and negative and positive infinity (see get_max_float in real.cc). This also makes the math all work. For example, suppose we know nothing about x and y (VARYING). On the TRUE side of x > y, we can deduce that: (a) x cannot be NAN (b) y cannot be NAN (c) y cannot be +INF. (c) means that we can drop the upper bound of "y" from +INF to the maximum representable value for its type. Having endpoints with different representation for infinity and the maximum representable values, means we can drop the +-INF properties we currently have in the frange. gcc/ChangeLog: * range-op-float.cc (frange_set_nan): New. (frange_drop_inf): New. (frange_drop_ninf): New. (foperator_equal::op1_range): Adjust for endpoints. (foperator_lt::op1_range): Same. (foperator_lt::op2_range): Same. (foperator_gt::op1_range): Same. (foperator_gt::op2_range): Same. (foperator_unordered::op1_range): Same. * value-query.cc (range_query::get_tree_range): Same. * value-range-pretty-print.cc (vrange_printer::visit): Same. * value-range-storage.cc (frange_storage_slot::get_frange): Same. * value-range.cc (frange::set): Same. (frange::normalize_kind): Same. (frange::union_): Same. (frange::intersect): Same. (frange::operator=): Same. (early_nan_resolve): New. (frange::contains_p): New. (frange::singleton_p): New. (frange::set_nonzero): New. (frange::nonzero_p): New. (frange::set_zero): New. (frange::zero_p): New. (frange::set_nonnegative): New. (frange_float): New. (frange_nan): New. (range_tests_nan): New. (range_tests_signed_zeros): New. (range_tests_floats): New. (range_tests): New. * value-range.h (frange::lower_bound): New. (frange::upper_bound): New. (vrp_val_min): Use real_inf with a sign instead of negating inf. (frange::frange): New. (frange::set_varying): Adjust for endpoints. (real_max_representable): New. (real_min_representable): New.
generated by cgit v1.1 at 2025-08-08 18:37:45 +0000