[PATCH 3/3] tree-optimization/108385 - Add op2_range to pointer_plus.

[PATCH 3/3] tree-optimization/108385 - Add op2_range to pointer_plus.

[Andrew MacLeod]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

Implement op2_range for pointer_plus to determine the offset (operand 2) 
is zero or non-zero based on equality/inequality between the LHS and op1.

Fairly trivial fix for the PR, dependent on the first patch in the set 
as it uses an accurate relation_trio in GORI to determine if LHS == OP1.


There was one tweak to GORI in that we use to stop calculating when the 
LHS was varying.  THis PR also exposed a case where the LHS is varying, 
but a relation between the operands can still cause us to find a useful 
result...  ie

VARYING = VARYING + OFFSET when LHS and OP1 are equal can produce a 
non-zero OFFSET calculation.

Bootstraps on x86_64-pc-linux-gnu with no regressions. OK for trunk?

Andrew


[-- Attachment #2: 0003-Add-op2_range-to-pointer_plus.patch --]
[-- Type: text/x-patch, Size: 4180 bytes --]

From 0730d9a6b856f6887bfffc4ce45d4164563a476e Mon Sep 17 00:00:00 2001
From: Andrew MacLeod <amacleod@redhat.com>
Date: Tue, 17 Jan 2023 11:39:47 -0500
Subject: [PATCH 3/3] Add op2_range to pointer_plus.

Implement op2_range for pointer_plus to determine the offset (operand 2) is
zero or non-zero based on equality/inequality between the LHS and op1.
Also allow GORI computations to continue if the LHS is VARYING and there
is also a relation.

	PR tree-optimization/108385
	gcc/
	* gimple-range-gori.cc (gori_compute::compute_operand_range):
	Allow VARYING computations to continue if there is a relation.
	* range-op.cc (pointer_plus_operator::op2_range): New.

	gcc/testsuite/
	* gcc.dg/pr108385.c: New.
---
 gcc/gimple-range-gori.cc        | 13 +++++++----
 gcc/range-op.cc                 | 23 +++++++++++++++++++
 gcc/testsuite/gcc.dg/pr108385.c | 39 +++++++++++++++++++++++++++++++++
 3 files changed, 71 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr108385.c

diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
index 3dc4576ff13..beb1c0064b9 100644
--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -607,10 +607,6 @@ gori_compute::compute_operand_range (vrange &r, gimple *stmt,
 {
   value_relation vrel;
   value_relation *vrel_ptr = rel;
-  // If the lhs doesn't tell us anything, neither will unwinding further.
-  if (lhs.varying_p ())
-    return false;
-
   // Empty ranges are viral as they are on an unexecutable path.
   if (lhs.undefined_p ())
     {
@@ -657,10 +653,19 @@ gori_compute::compute_operand_range (vrange &r, gimple *stmt,
   if (!op1_in_chain && !op2_in_chain)
     return false;
 
+  // If the lhs doesn't tell us anything and there are no relations, there
+  // is nothing to be learned.
+  if (lhs.varying_p () && !vrel_ptr)
+    return false;
+
   bool res;
   // Process logicals as they have special handling.
   if (is_gimple_logical_p (stmt))
     {
+      // If the lhs doesn't tell us anything, neither will combining operands.
+      if (lhs.varying_p ())
+	return false;
+
       unsigned idx;
       if ((idx = tracer.header ("compute_operand ")))
 	{
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index f7c1e84e0bd..136b709385c 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -4212,6 +4212,10 @@ public:
 		        const wide_int &lh_ub,
 		        const wide_int &rh_lb,
 		        const wide_int &rh_ub) const;
+  virtual bool op2_range (irange &r, tree type,
+			  const irange &lhs,
+			  const irange &op1,
+			  relation_trio = TRIO_VARYING) const;
 } op_pointer_plus;
 
 void
@@ -4258,6 +4262,25 @@ pointer_plus_operator::wi_fold (irange &r, tree type,
    r.set_varying (type);
 }
 
+bool
+pointer_plus_operator::op2_range (irange &r, tree type,
+				  const irange &lhs ATTRIBUTE_UNUSED,
+				  const irange &op1 ATTRIBUTE_UNUSED,
+				  relation_trio trio) const
+{
+  relation_kind rel = trio.lhs_op1 ();
+  r.set_varying (type);
+
+  // If the LHS and OP1 are equal, the op2 must be zero.
+  if (rel == VREL_EQ)
+    r.set_zero (type);
+  // If the LHS and OP1 are not equal, the offset must be non-zero.
+  else if (rel == VREL_NE)
+    r.set_nonzero (type);
+  else
+    return false;
+  return true;
+}
 
 class pointer_min_max_operator : public range_operator
 {
diff --git a/gcc/testsuite/gcc.dg/pr108385.c b/gcc/testsuite/gcc.dg/pr108385.c
new file mode 100644
index 00000000000..13babf06d9a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr108385.c
@@ -0,0 +1,39 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-evrp" } */
+
+void bar(char *);
+
+/* Ensure that PTR1 = PTR2 + OFF properly picks up the zero and non-zero
+   properties if PTR1 and PTR2 are known equal or non-equal.  */
+
+void foo1 (char *p, char *pp, int off)
+{
+  char *q = p + off;
+  if (q != p)
+    {
+      if (off == 0)
+	  bar (q);
+    }
+  else
+    {
+      if (off != 0)
+        bar (p);
+    }
+}
+
+void foo2 (char *p, char *pp, int off)
+{
+  char *q = p + off;
+  if (q == p)
+    {
+      if (off != 0)
+        bar (p);
+    }
+  else
+    {
+      if (off == 0)
+	  bar (q);
+    }
+}
+
+/* { dg-final { scan-tree-dump-not "bar" "evrp" } } */
-- 
2.39.0

Re: [PATCH 3/3] tree-optimization/108385 - Add op2_range to pointer_plus.

[Richard Biener]

On Mon, Jan 30, 2023 at 8:47 PM Andrew MacLeod via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> Implement op2_range for pointer_plus to determine the offset (operand 2)
> is zero or non-zero based on equality/inequality between the LHS and op1.
>
> Fairly trivial fix for the PR, dependent on the first patch in the set
> as it uses an accurate relation_trio in GORI to determine if LHS == OP1.
>
>
> There was one tweak to GORI in that we use to stop calculating when the
> LHS was varying.  THis PR also exposed a case where the LHS is varying,
> but a relation between the operands can still cause us to find a useful
> result...  ie
>
> VARYING = VARYING + OFFSET when LHS and OP1 are equal can produce a
> non-zero OFFSET calculation.
>
> Bootstraps on x86_64-pc-linux-gnu with no regressions. OK for trunk?

OK for the series.

Thanks,
Richard.

>
> Andrew
>