https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85964
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P2 Status|NEW |ASSIGNED CC| |rguenth at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- And the regression is likely for when I added static bool cleanup_tree_cfg_noloop (void) { ... /* Ensure that we have single entries into loop headers. Otherwise if one of the entries is becoming a latch due to CFG cleanup (from formerly being part of an irreducible region) then we mess up loop fixup and associate the old loop with a different region which makes niter upper bounds invalid. See for example PR80549. This needs to be done before we remove trivially dead edges as we need to capture the dominance state before the pending transform. */ if (current_loops) { ... /* If we have more than one entry to the loop header create a forwarder. */ if (found_latch && ! any_abnormal && n > 1) { edge fallthru = make_forwarder_block (bb, mfb_keep_latches, NULL); because make_forwarder_block adds a new block which in turn uses iterate_fix_dominators to fix dominators. We use dominators to find latches but we could split the analysis from the transform part and decide to throw away and re-compute dominators based on some threshold. Not sure if it is possible to estimate the work of iterate_fix_dominators up-front.