https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Aldy Hernandez <al...@gcc.gnu.org>: https://gcc.gnu.org/g:82cd78f2c31db1664ca154d7fcd24e9eaee1427f commit r12-4532-g82cd78f2c31db1664ca154d7fcd24e9eaee1427f Author: Aldy Hernandez <al...@redhat.com> Date: Wed Oct 20 09:05:23 2021 +0200 Restore --param=max-fsm-thread-length 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. Tested 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.
