public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Aldy Hernandez <aldyh@redhat.com>
To: GCC patches <gcc-patches@gcc.gnu.org>
Subject: [PUSHED] Abstract out conditional simplification out of execute_vrp.
Date: Mon, 26 Jul 2021 13:42:33 +0200	[thread overview]
Message-ID: <20210726114233.2402554-1-aldyh@redhat.com> (raw)

VRP simplifies conditionals involving casted values outside of the main
folding mechanism, because this optimization inhibits the VRP jump
threader from threading through the comparison.

As part of replacing VRP with an evrp instance, I am making sure we do
everything VRP does.  Hence, I am abstracting this functionality out so
we can call it from from elsewhere.

ISTM that when the proposed ranger-based jump threader can handle
everything the forward threader does, there will be no need for this
optimization to be done outside of the evrp folder.  Perhaps we can fold
this into the substitute_using_ranges class.  But that's further down
the line.

Also, there is no need to pass a vr_values around, when the base
range_query class will do.  I fixed this, at it makes it trivial to pass
down a ranger or evrp instance.

Tested on x86-64 Linux.

gcc/ChangeLog:

	* tree-vrp.c (vrp_simplify_cond_using_ranges): Rename vr_values
	with range_query.
	(execute_vrp): Abstract out simplification of conditionals...
	(simplify_casted_conds): ...here.
---
 gcc/tree-vrp.c | 39 +++++++++++++++++++++++----------------
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index a9c31bcedb5..58111f83183 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -4359,7 +4359,7 @@ vrp_jump_threader::after_dom_children (basic_block bb)
    subsequent passes.  */
 
 static void
-vrp_simplify_cond_using_ranges (vr_values *query, gcond *stmt)
+vrp_simplify_cond_using_ranges (range_query *query, gcond *stmt)
 {
   tree op0 = gimple_cond_lhs (stmt);
   tree op1 = gimple_cond_rhs (stmt);
@@ -4423,6 +4423,27 @@ vrp_simplify_cond_using_ranges (vr_values *query, gcond *stmt)
     }
 }
 
+/* A comparison of an SSA_NAME against a constant where the SSA_NAME
+   was set by a type conversion can often be rewritten to use the RHS
+   of the type conversion.  Do this optimization for all conditionals
+   in FUN.
+
+   However, doing so inhibits jump threading through the comparison.
+   So that transformation is not performed until after jump threading
+   is complete.  */
+
+static void
+simplify_casted_conds (function *fun, range_query *query)
+{
+  basic_block bb;
+  FOR_EACH_BB_FN (bb, fun)
+    {
+      gimple *last = last_stmt (bb);
+      if (last && gimple_code (last) == GIMPLE_COND)
+	vrp_simplify_cond_using_ranges (query, as_a <gcond *> (last));
+    }
+}
+
 /* Main entry point to VRP (Value Range Propagation).  This pass is
    loosely based on J. R. C. Patterson, ``Accurate Static Branch
    Prediction by Value Range Propagation,'' in SIGPLAN Conference on
@@ -4519,21 +4540,7 @@ execute_vrp (struct function *fun, bool warn_array_bounds_p)
   vrp_jump_threader threader (fun, &vrp_vr_values);
   threader.thread_jumps ();
 
-  /* A comparison of an SSA_NAME against a constant where the SSA_NAME
-     was set by a type conversion can often be rewritten to use the
-     RHS of the type conversion.
-
-     However, doing so inhibits jump threading through the comparison.
-     So that transformation is not performed until after jump threading
-     is complete.  */
-  basic_block bb;
-  FOR_EACH_BB_FN (bb, fun)
-    {
-      gimple *last = last_stmt (bb);
-      if (last && gimple_code (last) == GIMPLE_COND)
-	vrp_simplify_cond_using_ranges (&vrp_vr_values,
-					as_a <gcond *> (last));
-    }
+  simplify_casted_conds (fun, &vrp_vr_values);
 
   free_numbers_of_iterations_estimates (fun);
 
-- 
2.31.1


                 reply	other threads:[~2021-07-26 11:43 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210726114233.2402554-1-aldyh@redhat.com \
    --to=aldyh@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).