public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [COMMITTED] PR tree-optimization/102983 - Perform on-entry propagation after range_of_stmt on a gcond.
@ 2021-10-29 14:44 Andrew MacLeod
  0 siblings, 0 replies; only message in thread
From: Andrew MacLeod @ 2021-10-29 14:44 UTC (permalink / raw)
  To: gcc-patches

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

When range-of_stmt is invoked on a statement, out-of-date updating is 
keyed off the timestamp on the definition.

When the def is calculated, and its global value stored, a timestamp is 
created for the cache.  if range_of_stmt is invoked again, the timestamp 
of the uses are compared to the definitions, and if they are older, we 
simply use the cache value.

If one of the uses is newer than the definition, that means an input may 
have changed, and we will recalculate the definition. If this new value 
is different, we propagate this new value to any subsequent cache entries

In the case of a gcond, there is no LHS, so we ahev no way to determine 
if anything might be out of date or need updating. Until now, we just 
did nothing except calculate the branch... any cache entires in the 
following blocks were never updated.  In this PR, we later determines 
the b_4 has a value of 0 instead of [0,1] , which would then change the 
value of c in subsequent blocks.

This patch triggers a re-evaluation of all exports from a block when 
range_of_stmt is invoked on a gcond.  This isnt quite as bad as it seems 
because:
   a) range_of_stmt on a stmt without a LHS  is never invoked from 
within the internal API, so its only a client like VRP which can make 
this call
   b) The cache propagator is already smart enough to only propagate a 
value to the following blocks if
       1 - there is already an on-entry cache value, otherwise its skipped
       2 - the value actually changed.

The net result is that this change has very minimal impact on the 
compile time performance of the ranger VRP pass.. In the order of 0.5%.  
It also now catches a few things we use to miss.

Bootstrapped on x86_64-pc-linux-gnu with no regressions.  Pushed.

Andrew


[-- Attachment #2: 0001-Perform-on-entry-propagation-after-range_of_stmt-on-.patch --]
[-- Type: text/x-patch, Size: 3096 bytes --]

From cb596fd43667f92c4cb037a4ee8b2061c393ba60 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod <amacleod@redhat.com>
Date: Thu, 28 Oct 2021 13:31:17 -0400
Subject: [PATCH] Perform on-entry propagation after range_of_stmt on a gcond.

Propagation is automatically done by the temporal cache when defs are
out of date from the names on the RHS, but a gcond has no LHS, and any
updates on the RHS are never propagated.  Always propagate them.

	gcc/
	PR tree-optimization/102983
	* gimple-range-cache.h (propagate_updated_value): Make public.
	* gimple-range.cc (gimple_ranger::range_of_stmt): Propagate exports
	when processing gcond stmts.

	gcc/testsuite/
	* gcc.dg/pr102983.c: New.
---
 gcc/gimple-range-cache.h        |  4 ++--
 gcc/gimple-range.cc             | 12 +++++++++++-
 gcc/testsuite/gcc.dg/pr102983.c | 21 +++++++++++++++++++++
 3 files changed, 34 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr102983.c

diff --git a/gcc/gimple-range-cache.h b/gcc/gimple-range-cache.h
index 4937a0b305a..75105008338 100644
--- a/gcc/gimple-range-cache.h
+++ b/gcc/gimple-range-cache.h
@@ -103,6 +103,8 @@ public:
   bool get_non_stale_global_range (irange &r, tree name);
   void set_global_range (tree name, const irange &r);
 
+  void propagate_updated_value (tree name, basic_block bb);
+
   non_null_ref m_non_null;
   gori_compute m_gori;
 
@@ -120,8 +122,6 @@ private:
   void entry_range (irange &r, tree expr, basic_block bb);
   void exit_range (irange &r, tree expr, basic_block bb);
 
-  void propagate_updated_value (tree name, basic_block bb);
-
   bitmap m_propfail;
   vec<basic_block> m_workback;
   vec<basic_block> m_update_list;
diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
index 91bacda6dd0..2c9715a6f2c 100644
--- a/gcc/gimple-range.cc
+++ b/gcc/gimple-range.cc
@@ -256,7 +256,17 @@ gimple_ranger::range_of_stmt (irange &r, gimple *s, tree name)
 
   // If no name, simply call the base routine.
   if (!name)
-    res = fold_range_internal (r, s, NULL_TREE);
+    {
+      res = fold_range_internal (r, s, NULL_TREE);
+      if (res && is_a <gcond *> (s))
+	{
+	  // Update any exports in the cache if this is a gimple cond statement.
+	  tree exp;
+	  basic_block bb = gimple_bb (s);
+	  FOR_EACH_GORI_EXPORT_NAME (m_cache.m_gori, bb, exp)
+	    m_cache.propagate_updated_value (exp, bb);
+	}
+    }
   else if (!gimple_range_ssa_p (name))
     res = get_tree_range (r, name, NULL);
   // Check if the stmt has already been processed, and is not stale.
diff --git a/gcc/testsuite/gcc.dg/pr102983.c b/gcc/testsuite/gcc.dg/pr102983.c
new file mode 100644
index 00000000000..ef58af6def0
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr102983.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-evrp" } */
+void foo(void);
+
+static int a = 1;
+
+int main() {
+  int c = 0;
+  for (int b = 0; b <= 0; b++) {
+    if (!a)
+      foo();
+    if (b > c){
+      if (c)
+        continue;
+      a = 0;
+    }
+    c = 1;
+  }
+}
+
+/* { dg-final { scan-tree-dump-times "Folding predicate c_.* to 1" 1 "evrp" } } */
-- 
2.17.2


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2021-10-29 14:44 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-29 14:44 [COMMITTED] PR tree-optimization/102983 - Perform on-entry propagation after range_of_stmt on a gcond Andrew MacLeod

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).