Remove loop crossing restriction from the backward threader.
Commit Message
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).
OK pending tests on x86-64 Linux?
gcc/ChangeLog:
* tree-ssa-threadbackward.c
(back_threader_profitability::profitable_path_p): Remove loop
crossing restriction.
---
gcc/tree-ssa-threadbackward.c | 36 ++++++-----------------------------
1 file changed, 6 insertions(+), 30 deletions(-)
Comments
On 11/11/2021 10:24 AM, Aldy Hernandez wrote:
> 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).
>
> OK pending tests on x86-64 Linux?
>
> gcc/ChangeLog:
>
> * tree-ssa-threadbackward.c
> (back_threader_profitability::profitable_path_p): Remove loop
> crossing restriction.
OK
jeff
@@ -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,