Pass relations down to range_operator::op[12]_range.

Message ID 20211001124306.1458223-2-aldyh@redhat.com
State New
Headers
Series Pass relations down to range_operator::op[12]_range. |

Commit Message

Aldy Hernandez Oct. 1, 2021, 12:43 p.m. UTC
  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(-)
  

Comments

Andrew MacLeod Oct. 1, 2021, 1:38 p.m. UTC | #1
On 10/1/21 8:43 AM, Aldy Hernandez wrote:
> 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?


Hrm.  It's at least partial.  It will utilize relations as they exist at 
the query point, but they would not include any relations introduced by 
the unwind sequence.

at the If, there is no relation c_1 < a_2.  Its true we are checking the 
true edge, and in theory the relation should be registered on that true 
edge..  Perhaps I need to register the relation on the edge from the 
stmt before resolving the stmt rather than after like we currently do.

Let me think about that for a bit.

Andrew
  

Patch

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;