[gcc r12-5183] Remove loop crossing restriction from the backward threader.

[gcc r12-5183] Remove loop crossing restriction from the backward threader.

[Aldy Hernandez]

https://gcc.gnu.org/g:a7753db4a7c071fef7a4e7fe2650d6c59cc34066

commit r12-5183-ga7753db4a7c071fef7a4e7fe2650d6c59cc34066
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Thu Nov 11 16:12:32 2021 +0100

    Remove loop crossing restriction from the backward threader.
    
    We have much more thorough restrictions, that are shared between both
    threader implementations, in the registry.  I've been meaning to
    remove the backward threader one, since it's only purpose was reducing
    the search space.  Previously there was a small time penalty for its
    removal, but with the various patches in the past month, it looks like
    the removal is a wash performance wise.
    
    This catches 8 more jump threads in the backward threader in my suite.
    Presumably, because we disallowed all loop crossing, whereas the
    registry restrictions allow some crossing (if we exit the loop, etc).
    
    Tested on x86-64 Linux.
    
    gcc/ChangeLog:
    
            * tree-ssa-threadbackward.c
            (back_threader_profitability::profitable_path_p): Remove loop
            crossing restriction.

Diff:
---
 gcc/tree-ssa-threadbackward.c | 36 ++++++------------------------------
 1 file changed, 6 insertions(+), 30 deletions(-)

diff --git a/gcc/tree-ssa-threadbackward.c b/gcc/tree-ssa-threadbackward.c
index d067c470c38..61aee25d236 100644
--- a/gcc/tree-ssa-threadbackward.c
+++ b/gcc/tree-ssa-threadbackward.c
@@ -615,7 +615,6 @@ back_threader_profitability::profitable_path_p (const vec<basic_block> &m_path,
   int n_insns = 0;
   gimple_stmt_iterator gsi;
   loop_p loop = m_path[0]->loop_father;
-  bool path_crosses_loops = false;
   bool threaded_through_latch = false;
   bool multiway_branch_in_path = false;
   bool threaded_multiway_branch = false;
@@ -634,30 +633,15 @@ back_threader_profitability::profitable_path_p (const vec<basic_block> &m_path,
 
       if (dump_file && (dump_flags & TDF_DETAILS))
 	fprintf (dump_file, " bb:%i", bb->index);
-      /* Remember, blocks in the path are stored in opposite order
-	 in the PATH array.  The last entry in the array represents
-	 the block with an outgoing edge that we will redirect to the
-	 jump threading path.  Thus we don't care about that block's
-	 loop father, nor how many statements are in that block because
-	 it will not be copied or whether or not it ends in a multiway
-	 branch.  */
+      /* Remember, blocks in the path are stored in opposite order in
+	 the PATH array.  The last entry in the array represents the
+	 block with an outgoing edge that we will redirect to the jump
+	 threading path.  Thus we don't care how many statements are
+	 in that block because it will not be copied or whether or not
+	 it ends in a multiway branch.  */
       if (j < m_path.length () - 1)
 	{
 	  int orig_n_insns = n_insns;
-	  if (bb->loop_father != loop)
-	    {
-	      path_crosses_loops = true;
-
-	      // Dump rest of blocks.
-	      if (dump_file && (dump_flags & TDF_DETAILS))
-		for (j++; j < m_path.length (); j++)
-		  {
-		    bb = m_path[j];
-		    fprintf (dump_file, " bb:%i", bb->index);
-		  }
-	      break;
-	    }
-
 	  /* PHIs in the path will create degenerate PHIS in the
 	     copied path which will then get propagated away, so
 	     looking at just the duplicate path the PHIs would
@@ -776,14 +760,6 @@ back_threader_profitability::profitable_path_p (const vec<basic_block> &m_path,
 	*creates_irreducible_loop = true;
     }
 
-  if (path_crosses_loops)
-    {
-      if (dump_file && (dump_flags & TDF_DETAILS))
-	fprintf (dump_file, "  FAIL: Jump-thread path not considered: "
-		 "the path crosses loops.\n");
-      return false;
-    }
-
   /* Threading is profitable if the path duplicated is hot but also
      in a case we separate cold path from hot path and permit optimization
      of the hot path later.  Be on the agressive side here. In some testcases,