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 &r, const gimple *stmt, const irange &lhs_range) bool gimple_range_calc_op1 (irange &r, const gimple *stmt, - const irange &lhs_range, const irange &op2_range) + const irange &lhs_range, const irange &op2_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 &r, 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 &r, const gimple *stmt, bool gimple_range_calc_op2 (irange &r, const gimple *stmt, - const irange &lhs_range, const irange &op1_range) + const irange &lhs_range, const irange &op1_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 &r, 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 &r, 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 &r, 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 &r, 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 &r, 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