aboutsummaryrefslogtreecommitdiff
path: root/gcc/value-range.cc
AgeCommit message (Collapse)AuthorFilesLines
2023-04-18Add GTY support for vrange.Aldy Hernandez1-0/+85
IPA currently puts *some* irange's in GC memory. When I contribute support for generic ranges in IPA, we'll need to change this to vrange. This patch adds GTY support for both vrange and frange. gcc/ChangeLog: * value-range.cc (gt_ggc_mx): New. (gt_pch_nx): New. * value-range.h (class vrange): Add GTY marker. (class frange): Same. (gt_ggc_mx): Remove. (gt_pch_nx): Remove.
2023-04-18Declare dconstm0 to go along with dconst0 and friends.Aldy Hernandez1-4/+3
Negating dconst0 is getting pretty old, and we will keep adding copies of the same idiom. Fixed by adding a dconstm0 constant to go along with dconst1, dconstm1, etc. gcc/ChangeLog: * emit-rtl.cc (init_emit_once): Initialize dconstm0. * gimple-range-op.cc (class cfn_signbit): Remove dconstm0 declaration. * range-op-float.cc (zero_range): Use dconstm0. (zero_to_inf_range): Same. * real.h (dconstm0): New. * value-range.cc (frange::flush_denormals_to_zero): Use dconstm0. (frange::set_zero): Do not declare dconstm0.
2023-04-18Return true from operator== for two identical ranges containing NAN.Aldy Hernandez1-10/+0
The == operator for ranges signifies that two ranges contain the same thing, not that they are ultimately equal. So [2,4] == [2,4], even though one may be a 2 and the other may be a 3. Similarly with two VARYING ranges. There is an oversight in frange::operator== where we are returning false for two identical NANs. This is causing us to never cache NANs in sbr_sparse_bitmap::set_bb_range. gcc/ChangeLog: * value-range.cc (frange::operator==): Adjust for NAN. (range_tests_nan): Remove some NAN tests.
2023-04-18Add inchash support for vrange.Aldy Hernandez1-0/+52
This patch provides inchash support for vrange. It is along the lines of the streaming support I just posted and will be used for IPA hashing of ranges. gcc/ChangeLog: * inchash.cc (hash::add_real_value): New. * inchash.h (class hash): Add add_real_value. * value-range.cc (add_vrange): New. * value-range.h (inchash::add_vrange): New.
2023-03-28range-op-float: Only flush_denormals_to_zero for +-*/ [PR109154]Jakub Jelinek1-2/+0
As discussed in the PR, flushing denormals to zero on every frange::set might be harmful for e.g. x < 0.0 comparisons, because we then on both sides use ranges that include zero [-Inf, -0.0] on the true side, and [-0.0, +Inf] NAN on the false side, rather than [-Inf, nextafter (-0.0, -Inf)] on the true side. The following patch does it only in range_operator_float::fold_range which is right now used for +-*/ (both normal and reverse ops of those). Though, I don't see any difference on the testcase in the PR, but not sure what I should be looking at and the reduced testcase there has undefined behavior. 2023-03-28 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/109154 * value-range.h (frange::flush_denormals_to_zero): Make it public rather than private. * value-range.cc (frange::set): Don't call flush_denormals_to_zero here. * range-op-float.cc (range_operator_float::fold_range): Call flush_denormals_to_zero.
2023-03-23ranger: Ranger meets aspellJakub Jelinek1-2/+2
I've noticed a comment typo in tree-vrp.cc and decided to quickly skim aspell -c on the ranger sources (with quick I on everything that looked ok or roughly ok). But not being a native English speaker, I could get stuff wrong. 2023-03-23 Jakub Jelinek <jakub@redhat.com> * value-range.cc (irange::irange_union, irange::intersect): Fix comment spelling bugs. * gimple-range-trace.cc (range_tracer::do_header): Likewise. * gimple-range-trace.h: Likewise. * gimple-range-edge.cc: Likewise. (gimple_outgoing_range_stmt_p, gimple_outgoing_range::switch_edge_range, gimple_outgoing_range::edge_range_p): Likewise. * gimple-range.cc (gimple_ranger::prefill_stmt_dependencies, gimple_ranger::fold_stmt, gimple_ranger::register_transitive_infer, assume_query::assume_query, assume_query::calculate_phi): Likewise. * gimple-range-edge.h: Likewise. * value-range.h (Value_Range::set, Value_Range::lower_bound, Value_Range::upper_bound, frange::set_undefined): Likewise. * gimple-range-gori.h (range_def_chain::depend, gori_map::m_outgoing, gori_compute): Likewise. * gimple-range-fold.h (fold_using_range): Likewise. * gimple-range-path.cc (path_range_query::compute_ranges_in_phis): Likewise. * gimple-range-gori.cc (range_def_chain::in_chain_p, range_def_chain::dump, gori_map::calculate_gori, gori_compute::compute_operand_range_switch, gori_compute::logical_combine, gori_compute::refine_using_relation, gori_compute::compute_operand1_range, gori_compute::may_recompute_p): Likewise. * gimple-range.h: Likewise. (enable_ranger): Likewise. * range-op.h (empty_range_varying): Likewise. * value-query.h (value_query): Likewise. * gimple-range-cache.cc (block_range_cache::set_bb_range, block_range_cache::dump, ssa_global_cache::clear_global_range, temporal_cache::temporal_value, temporal_cache::current_p, ranger_cache::range_of_def, ranger_cache::propagate_updated_value, ranger_cache::range_from_dom, ranger_cache::register_inferred_value): Likewise. * gimple-range-fold.cc (fur_edge::get_phi_operand, fur_stmt::get_operand, gimple_range_adjustment, fold_using_range::range_of_phi, fold_using_range::relation_fold_and_or): Likewise. * value-range-storage.h (irange_storage_slot::MAX_INTS): Likewise. * value-query.cc (range_query::value_of_expr, range_query::value_on_edge, range_query::query_relation): Likewise. * tree-vrp.cc (remove_unreachable::remove_and_update_globals, intersect_range_with_nonzero_bits): Likewise. * gimple-range-infer.cc (gimple_infer_range::check_assume_func, exit_range): Likewise. * value-relation.h: Likewise. (equiv_oracle, relation_trio::relation_trio, value_relation, value_relation::value_relation, pe_min): Likewise. * range-op-float.cc (range_operator_float::rv_fold, frange_arithmetic, foperator_unordered_equal::op1_range, foperator_div::rv_fold): Likewise. * gimple-range-op.cc (cfn_clz::fold_range): Likewise. * value-relation.cc (equiv_oracle::query_relation, equiv_oracle::register_equiv, equiv_oracle::add_equiv_to_block, value_relation::apply_transitive, relation_chain_head::find_relation, dom_oracle::query_relation, dom_oracle::find_relation_block, dom_oracle::find_relation_dom, path_oracle::register_equiv): Likewise. * range-op.cc (range_operator::wi_fold_in_parts_equiv, create_possibly_reversed_range, adjust_op1_for_overflow, operator_mult::wi_fold, operator_exact_divide::op1_range, operator_cast::lhs_op1_relation, operator_cast::fold_pair, operator_cast::fold_range, operator_abs::wi_fold, range_op_cast_tests, range_op_lshift_tests): Likewise.
2023-03-22frange: Implement nan_state class [PR109008]Aldy Hernandez1-3/+15
This patch implements a nan_state class, that allows us to query or pass around the NANness of an frange. We can store +NAN, -NAN, +-NAN, or not-a-NAN with it. I tried to touch as little as possible, leaving other cleanups to the next release. For example, we should replace the m_*_nan fields in frange with nan_state, and provide relevant accessors to nan_state (isnan, etc). PR tree-optimization/109008 gcc/ChangeLog: * value-range.cc (frange::set): Add nan_state argument. * value-range.h (class nan_state): New. (frange::get_nan_state): New.
2023-02-03irange: Compare nonzero bits in irange with widest_int [PR108639]Aldy Hernandez1-2/+9
The problem here is we are trying to compare two ranges with different precisions and the == operator in wide_int is complaining. Interestingly, the problem is not the nonzero bits, but the fact that the entire ranges have different precisions. The reason we don't ICE when comparing the sub-ranges, is because the code in irange::operator== works on trees, and tree_int_cst_equal is promoting the comparison to a widest int: if (TREE_CODE (t1) == INTEGER_CST && TREE_CODE (t2) == INTEGER_CST && wi::to_widest (t1) == wi::to_widest (t2)) return 1; This is why we don't see the ICE until the nonzero bits comparison is done on wide ints. I think we should maintain the current equality behavior, and follow suit in the nonzero bit comparison. I have also fixed the legacy equality code, even though technically nonzero bits shouldn't appear in legacy. But better safe than sorry. PR tree-optimization/108639 gcc/ChangeLog: * value-range.cc (irange::legacy_equal_p): Compare nonzero bits as widest_int. (irange::operator==): Same.
2023-01-02Update copyright years.Jakub Jelinek1-1/+1
2022-11-12[frange] Avoid testing signed zero test for -fno-signed-zeros.Aldy Hernandez1-4/+5
This patch moves a test that is meant to only work for signed zeros into range_tests_signed_zeros. I am not aware of any architectures where this is failing, but it is annoying to see selftests failing when -fno-signed-zeros is used. gcc/ChangeLog: * value-range.cc (range_tests_signbit): Move to set from here... (range_tests_signed_zeros): ...to here.
2022-11-10Do not specify NAN sign in frange::set_nonnegative.Aldy Hernandez1-5/+7
After further reading of the IEEE 754 standard, it has become clear that there are no guarantees with regards to the sign of a NAN when it comes to any operation other than copy, copysign, abs, and negate. Currently, set_nonnegative() is only used in one place in ranger applicable to floating point values, when expanding unknown calls. Since we already specially handle copy, copysign, abs, and negate, all the calls to set_nonnegative() must be NAN-sign agnostic. The cleanest solution is to leave the sign unspecificied in frange::set_nonnegative(). Any special case, must be handled by the caller. gcc/ChangeLog: * value-range.cc (frange::set_nonnegative): Remove NAN sign handling. (range_tests_signed_zeros): Adjust test.
2022-11-09Clear NAN when reading back a global range if necessary.Aldy Hernandez1-0/+9
When reading back from the global store, we must clear the NAN bit if necessary. The reason it's not happening is because the constructor sets a NAN by default (when HONOR_NANS). We must be careful to clear the NAN bit if the original range didn't have a NAN. I have commented the reason we use the constructor instead of filling out the fields by hand, because it wasn't clear at re-reading this code. PR 107569/tree-optimization gcc/ChangeLog: * value-range-storage.cc (frange_storage_slot::get_frange): Clear NAN if appropriate. * value-range.cc (range_tests_floats): New test.
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.
generated by cgit v1.1 at 2025-08-07 19:32:05 +0000