Restore --param=max-fsm-thread-length
Commit Message
The removal of --param=max-fsm-thread-length is causing code
explosion. I thought that --param=max-fsm-thread-path-insns was a
better gague for path profitability than raw BB length, but it turns
out that we don't take into account PHIs when estimating the number of
statements.
In this PR, we have a sequence of very large PHIs that have us
traversing extremely large paths that blow up the compilation.
We could fix this a couple of different ways. We could avoid
traversing more than a certain number of PHI arguments, or ignore
large PHIs altogether. The old implementation certainly had this
knob, and we could cut things off before we even got to the ranger.
We could also adjust the instruction estimation to take into account
PHIs, but I'm sure we'll mess something else in the process ;-).
The easiest thing to do is just restore the knob.
At a later time we could tweak this further, for instance,
disregarding empty blocks in the count. BTW, this is the reason I
didn't chop things off in the lowlevel registry for all threaders: the
forward threader can't really explore too deep paths, but it could
theoretically get there while threading over empty blocks.
This fixes 102814, 102852, and I bet it solves the Linux kernel cross
compile issue.
I will commit this pending tests on x86-64 Linux.
gcc/ChangeLog:
PR tree-optimization/102814
* doc/invoke.texi: Document --param=max-fsm-thread-length.
* params.opt: Add --param=max-fsm-thread-length.
* tree-ssa-threadbackward.c
(back_threader_profitability::profitable_path_p): Fail on paths
longer than max-fsm-thread-length.
---
gcc/doc/invoke.texi | 3 +++
gcc/params.opt | 4 ++++
gcc/tree-ssa-threadbackward.c | 9 +++++++++
3 files changed, 16 insertions(+)
Comments
On Wed, 2021-10-20 09:43:42 +0200, Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> The removal of --param=max-fsm-thread-length is causing code
> explosion. I thought that --param=max-fsm-thread-path-insns was a
> better gague for path profitability than raw BB length, but it turns
> out that we don't take into account PHIs when estimating the number of
> statements.
[...]
>
> This fixes 102814, 102852, and I bet it solves the Linux kernel cross
> compile issue.
It does!
Thanks,
Jan-Benedict
--
@@ -14468,6 +14468,9 @@ Emit instrumentation calls to __tsan_func_entry() and __tsan_func_exit().
Maximum number of instructions to copy when duplicating blocks on a
finite state automaton jump thread path.
+@item max-fsm-thread-length
+Maximum number of basic blocks on a jump thread path.
+
@item parloops-chunk-size
Chunk size of omp schedule for loops parallelized by parloops.
@@ -533,6 +533,10 @@ The maximum number of nested indirect inlining performed by early inliner.
Common Joined UInteger Var(param_max_fields_for_field_sensitive) Param
Maximum number of fields in a structure before pointer analysis treats the structure as a single variable.
+-param=max-fsm-thread-length=
+Common Joined UInteger Var(param_max_fsm_thread_length) Init(10) IntegerRange(1, 999999) Param Optimization
+Maximum number of basic blocks on a jump thread path.
+
-param=max-fsm-thread-path-insns=
Common Joined UInteger Var(param_max_fsm_thread_path_insns) Init(100) IntegerRange(1, 999999) Param Optimization
Maximum number of instructions to copy when duplicating blocks on a finite state automaton jump thread path.
@@ -620,6 +620,15 @@ back_threader_profitability::profitable_path_p (const vec<basic_block> &m_path,
if (m_path.length () <= 1)
return false;
+ if (m_path.length () > (unsigned) param_max_fsm_thread_length)
+ {
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ fprintf (dump_file, " FAIL: Jump-thread path not considered: "
+ "the number of basic blocks on the path "
+ "exceeds PARAM_MAX_FSM_THREAD_LENGTH.\n");
+ return false;
+ }
+
int n_insns = 0;
gimple_stmt_iterator gsi;
loop_p loop = m_path[0]->loop_father;