I think things are clear enough to propose a patch. Thanks for everyone's input. I have added some comments and tweaked Michael's patch to include the final BB where we're threading to, in the check. Without this last check, we fail in tree-ssa/cunroll-15.c because the latch becomes polluted with PHI nodes. OK for trunk? Aldy commit e735a2cd01485773635bd66c97af21059992d5a7 (HEAD -> pending/global-ranges) Author: Aldy Hernandez Date: Thu Sep 9 20:30:28 2021 +0200 Disable threading through latches until after loop optimizations. The motivation for this patch was enabling the use of global ranges in the path solver, but this caused certain properties of loops being destroyed which made subsequent loop optimizations to fail. Consequently, this patch's mail goal is to disable jump threading involving the latch until after loop optimizations have run. I have added a bit in cfun to indicate when the "loopdone" optimization has completed. This helps the path threader determine when it's safe to thread through loop structures. I can adapt the patch if there is an alternate way of determining this. As can be seen in the test adjustments, we mostly shift the threading from the early threaders (ethread, thread[12] to the late threaders thread[34]). I have nuked some of the early notes in the testcases that came as part of the jump threader rewrite. They're mostly noise now. Note that we could probably relax some other restrictions in profitable_path_p when loop optimizations have completed, but it would require more testing, and I'm hesitant to touch more things than needed at this point. I have added a reminder to the function to keep this in mind. Finally, perhaps as a follow-up, we should apply the same restrictions to the forward threader. At some point I'd like to combine the cost models. Tested on x86-64 Linux. p.s. There is a thorough discussion involving the limitations of jump threading involving loops here: https://gcc.gnu.org/pipermail/gcc/2021-September/237247.html