public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] Speedup update-ssa some more
Date: Thu, 7 Jul 2022 11:03:46 +0000 (UTC)	[thread overview]
Message-ID: <20220707110346.auFJqbrM2nbRFN09be34DBpGVgZv1cCgZ4kcA4BYg5A@z> (raw)

The following avoids copying an sbitmap and one traversal by avoiding
to re-allocate old_ssa_names when not necessary.  In addition this
actually checks what the comment before PHI insert iterating promises,
that the old_ssa_names set does not grow.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

	* tree-into-ssa.cc (iterating_old_ssa_names): New.
	(add_new_name_mapping): Grow {new,old}_ssa_names separately
	and only when actually needed.  Assert we are not growing
	the old_ssa_names set when iterating over it.
	(update_ssa): Remove old_ssa_names copying and empty_p
	query, note we are iterating over it and expect no set changes.
---
 gcc/tree-into-ssa.cc | 36 ++++++++++++++++++++----------------
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/gcc/tree-into-ssa.cc b/gcc/tree-into-ssa.cc
index c90651c3a89..9f45e62c6d0 100644
--- a/gcc/tree-into-ssa.cc
+++ b/gcc/tree-into-ssa.cc
@@ -587,6 +587,8 @@ add_to_repl_tbl (tree new_tree, tree old)
   bitmap_set_bit (*set, SSA_NAME_VERSION (old));
 }
 
+/* Debugging aid to fence old_ssa_names changes when iterating over it.  */
+static bool iterating_old_ssa_names;
 
 /* Add a new mapping NEW_TREE -> OLD REPL_TBL.  Every entry N_i in REPL_TBL
    represents the set of names O_1 ... O_j replaced by N_i.  This is
@@ -602,10 +604,15 @@ add_new_name_mapping (tree new_tree, tree old)
 
   /* We may need to grow NEW_SSA_NAMES and OLD_SSA_NAMES because our
      caller may have created new names since the set was created.  */
-  if (SBITMAP_SIZE (new_ssa_names) <= num_ssa_names - 1)
+  if (SBITMAP_SIZE (new_ssa_names) <= SSA_NAME_VERSION (new_tree))
     {
       unsigned int new_sz = num_ssa_names + NAME_SETS_GROWTH_FACTOR;
       new_ssa_names = sbitmap_resize (new_ssa_names, new_sz, 0);
+    }
+  if (SBITMAP_SIZE (old_ssa_names) <= SSA_NAME_VERSION (old))
+    {
+      gcc_assert (!iterating_old_ssa_names);
+      unsigned int new_sz = num_ssa_names + NAME_SETS_GROWTH_FACTOR;
       old_ssa_names = sbitmap_resize (old_ssa_names, new_sz, 0);
     }
 
@@ -619,8 +626,11 @@ add_new_name_mapping (tree new_tree, tree old)
 
   /* Register NEW_TREE and OLD in NEW_SSA_NAMES and OLD_SSA_NAMES,
      respectively.  */
+  if (iterating_old_ssa_names)
+    gcc_assert (bitmap_bit_p (old_ssa_names, SSA_NAME_VERSION (old)));
+  else
+    bitmap_set_bit (old_ssa_names, SSA_NAME_VERSION (old));
   bitmap_set_bit (new_ssa_names, SSA_NAME_VERSION (new_tree));
-  bitmap_set_bit (old_ssa_names, SSA_NAME_VERSION (old));
 }
 
 
@@ -3460,20 +3470,14 @@ update_ssa (unsigned update_flags)
 	bitmap_initialize (&dfs[bb->index], &bitmap_default_obstack);
       compute_dominance_frontiers (dfs);
 
-      if (bitmap_first_set_bit (old_ssa_names) >= 0)
-	{
-	  sbitmap_iterator sbi;
-
-	  /* insert_update_phi_nodes_for will call add_new_name_mapping
-	     when inserting new PHI nodes, so the set OLD_SSA_NAMES
-	     will grow while we are traversing it (but it will not
-	     gain any new members).  Copy OLD_SSA_NAMES to a temporary
-	     for traversal.  */
-	  auto_sbitmap tmp (SBITMAP_SIZE (old_ssa_names));
-	  bitmap_copy (tmp, old_ssa_names);
-	  EXECUTE_IF_SET_IN_BITMAP (tmp, 0, i, sbi)
-	    insert_updated_phi_nodes_for (ssa_name (i), dfs, update_flags);
-	}
+      /* insert_update_phi_nodes_for will call add_new_name_mapping
+	 when inserting new PHI nodes, but it will not add any
+	 new members to OLD_SSA_NAMES.  */
+      iterating_old_ssa_names = true;
+      sbitmap_iterator sbi;
+      EXECUTE_IF_SET_IN_BITMAP (old_ssa_names, 0, i, sbi)
+	insert_updated_phi_nodes_for (ssa_name (i), dfs, update_flags);
+      iterating_old_ssa_names = false;
 
       symbols_to_rename.qsort (insert_updated_phi_nodes_compare_uids);
       FOR_EACH_VEC_ELT (symbols_to_rename, i, sym)
-- 
2.35.3

             reply	other threads:[~2022-07-07 11:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-07 11:03 Richard Biener [this message]
2022-07-07 11:03 Richard Biener
2022-07-07 11:03 Richard Biener

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=20220707110346.auFJqbrM2nbRFN09be34DBpGVgZv1cCgZ4kcA4BYg5A@z \
    --to=rguenther@suse.de \
    --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).