[gcc r13-1934] Properly honor param_max_fsm_thread_path_insns in backwards threader

[gcc r13-1934] Properly honor param_max_fsm_thread_path_insns in backwards threader

[Richard Biener]

https://gcc.gnu.org/g:353fd1ec3df92fbe66ce1513c5a86bdd5c5e22d1

commit r13-1934-g353fd1ec3df92fbe66ce1513c5a86bdd5c5e22d1
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Aug 2 09:58:44 2022 +0200

    Properly honor param_max_fsm_thread_path_insns in backwards threader
    
    I am trying to make sense of back_threader_profitability::profitable_path_p
    and the first thing I notice is that we do
    
      /* 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,
         as in PR 78407 this leads to noticeable improvements.  */
      if (m_speed_p
          && ((taken_edge && optimize_edge_for_speed_p (taken_edge))
              || contains_hot_bb))
        {
          if (n_insns >= param_max_fsm_thread_path_insns)
            {
              if (dump_file && (dump_flags & TDF_DETAILS))
                fprintf (dump_file, "  FAIL: Jump-thread path not considered: "
                         "the number of instructions on the path "
                         "exceeds PARAM_MAX_FSM_THREAD_PATH_INSNS.\n");
              return false;
            }
    ...
        }
      else if (!m_speed_p && n_insns > 1)
        {
          if (dump_file && (dump_flags & TDF_DETAILS))
            fprintf (dump_file, "  FAIL: Jump-thread path not considered: "
                     "duplication of %i insns is needed and optimizing for size.\n",
                     n_insns);
          return false;
        }
    ...
      return true;
    
    thus we apply the n_insns >= param_max_fsm_thread_path_insns only
    to "hot paths".  The comment above this isn't entirely clear whether
    this is by design ("Be on the aggressive side here ...") but I think
    this is a mistake.  In fact the "hot path" check seems entirely
    useless since if the path is not hot we simply continue threading it.
    
    This was caused by r12-324-g69e5544210e3c0 and the following simply
    reverts the offending change.
    
            * tree-ssa-threadbackward.cc
            (back_threader_profitability::profitable_path_p): Apply
            size constraints to all paths again.

Diff:
---
 gcc/tree-ssa-threadbackward.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-ssa-threadbackward.cc b/gcc/tree-ssa-threadbackward.cc
index 0519f2a8c4b..ba114e98a41 100644
--- a/gcc/tree-ssa-threadbackward.cc
+++ b/gcc/tree-ssa-threadbackward.cc
@@ -794,7 +794,7 @@ back_threader_profitability::profitable_path_p (const vec<basic_block> &m_path,
 	  return false;
 	}
     }
-  else if (!m_speed_p && n_insns > 1)
+  else if (n_insns > 1)
     {
       if (dump_file && (dump_flags & TDF_DETAILS))
 	fprintf (dump_file, "  FAIL: Jump-thread path not considered: "