It looks like we don't pass relations down to the op[12]_range
operators. This is causing problems when implementing some relational
magic for the shift operators.
Andrew, this looks like an oversight. If so, how does this look?
Tested on x86-64 Linux.
gcc/ChangeLog:
* gimple-range-gori.cc (gimple_range_calc_op1): Add relation argument.
(gimple_range_calc_op2): Same.
(gori_compute::compute_operand1_range): Pass relation to
gimple_range_calc_op*.
(gori_compute::compute_operand2_range): Same.
---
gcc/gimple-range-gori.cc | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
index 4a1ade7f921..c7cfb71d849 100644
--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -59,7 +59,8 @@ gimple_range_calc_op1 (irange , const gimple *stmt, const
irange _range)
bool
gimple_range_calc_op1 (irange , const gimple *stmt,
- const irange _range, const irange _range)
+ const irange _range, const irange _range,
+ relation_kind rel)
{
// Unary operation are allowed to pass a range in for second operand
// as there are often additional restrictions beyond the type which
@@ -72,7 +73,7 @@ gimple_range_calc_op1 (irange , const gimple *stmt,
return true;
}
return gimple_range_handler (stmt)->op1_range (r, type, lhs_range,
-op2_range);
+op2_range, rel);
}
// Calculate what we can determine of the range of this statement's
@@ -82,7 +83,8 @@ gimple_range_calc_op1 (irange , const gimple *stmt,
bool
gimple_range_calc_op2 (irange , const gimple *stmt,
- const irange _range, const irange _range)
+ const irange _range, const irange _range,
+ relation_kind rel)
{
tree type = TREE_TYPE (gimple_range_operand2 (stmt));
// An empty range is viral.
@@ -92,7 +94,7 @@ gimple_range_calc_op2 (irange , const gimple *stmt,
return true;
}
return gimple_range_handler (stmt)->op2_range (r, type, lhs_range,
-op1_range);
+op1_range, rel);
}
// Return TRUE if GS is a logical && or || expression.
@@ -1000,6 +1002,12 @@ gori_compute::compute_operand1_range (irange , gimple
*stmt,
int_range_max op1_range, op2_range;
tree op1 = gimple_range_operand1 (stmt);
tree op2 = gimple_range_operand2 (stmt);
+ relation_kind rel;
+
+ if (op1 && op2)
+rel = src.query_relation (op1, op2);
+ else
+rel = VREL_NONE;
// Fetch the known range for op1 in this block.
src.get_operand (op1_range, op1);
@@ -1008,7 +1016,7 @@ gori_compute::compute_operand1_range (irange , gimple
*stmt,
if (op2)
{
src.get_operand (op2_range, op2);
- if (!gimple_range_calc_op1 (r, stmt, lhs, op2_range))
+ if (!gimple_range_calc_op1 (r, stmt, lhs, op2_range, rel))
return false;
}
else
@@ -1016,7 +1024,7 @@ gori_compute::compute_operand1_range (irange , gimple
*stmt,
// We pass op1_range to the unary operation. Nomally it's a
// hidden range_for_type parameter, but sometimes having the
// actual range can result in better information.
- if (!gimple_range_calc_op1 (r, stmt, lhs, op1_range))
+ if (!gimple_range_calc_op1 (r, stmt, lhs, op1_range, rel))
return false;
}
@@ -1077,12 +1085,18 @@ gori_compute::compute_operand2_range (irange , gimple
*stmt,
int_range_max op1_range, op2_range;
tree op1 = gimple_range_operand1 (stmt);
tree op2 = gimple_range_operand2 (stmt);
+ relation_kind rel;
+
+ if (op1 && op2)
+rel = src.query_relation (op1, op2);
+ else
+rel = VREL_NONE;
src.get_operand (op1_range, op1);
src.get_operand (op2_range, op2);
// Intersect with range for op2 based on lhs and op1.
- if (!gimple_range_calc_op2 (r, stmt, lhs, op1_range))
+ if (!gimple_range_calc_op2 (r, stmt, lhs, op1_range, rel))
return false;
unsigned idx;
--
2.31.1