On 11/5/2021 9:09 AM, Aldy Hernandez wrote:
The main path discovery function was due for a cleanup.  First,
there's a nagging goto and second, my bitmap use was sloppy.  Hopefully
this makes the code easier for others to read.

Regstrapped on x86-64 Linux.  I also made sure there were no difference
in the number of threads with this patch.

No functional changes.

OK?

gcc/ChangeLog:

        * tree-ssa-threadbackward.c (back_threader::find_paths_to_names):
        Remove gotos and other cleanups.
---
  gcc/tree-ssa-threadbackward.c | 52 ++++++++++++++---------------------
  1 file changed, 20 insertions(+), 32 deletions(-)

diff --git a/gcc/tree-ssa-threadbackward.c b/gcc/tree-ssa-threadbackward.c
index b7eaff94567..d6a5b0b8da2 100644
--- a/gcc/tree-ssa-threadbackward.c
+++ b/gcc/tree-ssa-threadbackward.c
@@ -402,26 +402,18 @@ back_threader::find_paths_to_names (basic_block bb, 
bitmap interesting)
m_path.safe_push (bb); + // Try to resolve the path without looking back.
    if (m_path.length () > 1
-      && !m_profit.profitable_path_p (m_path, m_name, NULL))
+      && (!m_profit.profitable_path_p (m_path, m_name, NULL)
+         || maybe_register_path ()))
      {
        m_path.pop ();
        m_visited_bbs.remove (bb);
        return false;
      }
- // Try to resolve the path without looking back.
-  if (m_path.length () > 1 && maybe_register_path ())
-    {
-      m_path.pop ();
-      m_visited_bbs.remove (bb);
-      return true;
-    }
Hmm, note the return values are different in these cases, which you've merged to always return false.    I was about to suggest you just kill the return value and the cleanups that would enable.  But I see your patch uses the return value where we didn't before.

So I think that raises the question, for the recursive calls which set "done", does the change in return value, particularly when maybe_register_path returns true impact anything?

jeff

Reply via email to