On 11/5/2021 9:09 AM, Aldy Hernandez wrote:
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.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; - }
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
