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.
