https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #31 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-14 branch has been updated by Richard Biener <rgue...@gcc.gnu.org>: https://gcc.gnu.org/g:987a7b58bf2a00936ee2f418ace7c596450a17cb commit r14-10773-g987a7b58bf2a00936ee2f418ace7c596450a17cb Author: Richard Biener <rguent...@suse.de> Date: Tue Aug 6 14:56:26 2024 +0200 tree-optimization/116166 - forward jump-threading going wild Currently the forward threader isn't limited as to the search space it explores and with it now using path-ranger for simplifying conditions it runs into it became pretty slow for degenerate cases like compiling insn-emit.cc for RISC-V esp. when compiling for a host with LOGICAL_OP_NON_SHORT_CIRCUIT disabled. The following makes the forward threader honor the search space limit I introduced for the backward threader. This reduces compile-time from minutes to seconds for the testcase in PR116166. Note this wasn't necessary before we had ranger but with ranger the work we do is quadatic in the length of the threading path we build up (the same is true for the backwards threader). PR tree-optimization/116166 * tree-ssa-threadedge.h (jump_threader::thread_around_empty_blocks): Add limit parameter. (jump_threader::thread_through_normal_block): Likewise. * tree-ssa-threadedge.cc (jump_threader::thread_around_empty_blocks): Honor and decrement limit parameter. (jump_threader::thread_through_normal_block): Likewise. (jump_threader::thread_across_edge): Initialize limit from param_max_jump_thread_paths and pass it down to workers. (cherry picked from commit 2cf89ae83225f932b226cd57ef2d083a59bcf8a3)
