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.
---
gcc/value-range.cc | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index e1066f4946e..6e196574de9 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -2934,6 +2934,14 @@ irange::set_nonzero_bits (const wide_int_ref &bits)
// range immediately.
if (wi::popcount (bits) == 1)
{
+ // Make sure we don't pessimize the range.
+ tree tbits = wide_int_to_tree (type (), bits);
+ if (!contains_p (tbits))
+ {
+ set_nonzero_bits (tbits);
+ return;
+ }
+
bool has_zero = contains_p (build_zero_cst (type ()));
set (type (), bits, bits);
if (has_zero)
@@ -3628,6 +3636,11 @@ range_tests_nonzero_bits ()
r1.set_nonzero_bits (0xff);
r0.union_ (r1);
ASSERT_TRUE (r0.varying_p ());
+
+ // Test that setting a nonzero bit of 1 does not pessimize the range.
+ r0.set_zero (integer_type_node);
+ r0.set_nonzero_bits (1);
+ ASSERT_TRUE (r0.zero_p ());
}
// Build an frange from string endpoints.
--
2.37.1
