https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #23 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Richard Biener from comment #20) > collected sofar. I've noticed with the backwards threader that path > ranger isn't very good in the ability to preserve a cache when adding > blocks. But in the case of forward threading resetting the cache shouldn't I know only a little about the path ranger. I believe it is primarily a path finding class which uses ranger to provide ranges on entry ot the path, and then goes and walks the various path combinations utilizing GORI to calculate any outgoing ranges of ssa-names it thinks are interesting to determine if any conditions can folded on some path(s). > be necessary - we might get additional "interesting" names to analyze but > already analyzed names do not need re-analyzing (as opposed to the backward > threader where we add blocks at the start of the path and thus would > possibly get refined ranges). We only need to clear the cache when > popping blocks - and even then only for names defined in the popped block. > > A more pragmatic fix would be to limit the number of EDGE_NO_COPY_SRC_BLOCK > blocks we add to the path aka the depth of the thread_around_empty_blocks > recursion. Limiting that to 10 for example makes the testcase compile in 1s. > Implementing search space limiting and re-using --param max-jump-thread-paths > works as well, resulting in 3s. If there are no limits on its depth, well that could be a problem :-) Aldy Understands this much better, we should engage him upon his return.
