https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128277
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to work| |17.0
Summary|[14/15/16/17 Regression] |[14/15/16 Regression]
|Compile-time hog in ccp1 at |Compile-time hog in ccp1 at
|-O1 on a loop header with |-O1 on a loop header with
|many latch edges since |many latch edges since
|r13-5102 |r13-5102
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mitigated on trunk. As you said the previous change was on purpose as we've
observed faster convergence. It's always difficult to guess whether completing
inner cycles first before outer cycles is faster. The exact situation might
warrant special-casing cycles with the same header, but I'm sure you can
construct a testcase where it shows that would not help, like with multiple
uniform header PHIs that only have a distinct value on one of the latch edges
and that only becomes executable when a condition on the previous PHI becomes
VARYING.
# _1 = PHI <0, 1(a), 0(b)>
# _2 = PHI <0, 0(a), 1(b)>
..
if (_1)
a: goto header;
if (_2)
b: goto header;
etc. That requires N iterations. If iterating the whole cycle it visits
all stmts N times, if iterating back to the header it visits only half
of the total stmts (you can reverse the controls and get the bad time as well
I guess).
Having a single latch might prevent some optimizations, but I'm not sure about
that.
The alternative is to put a limit on the number of times a block is visited
and drop backedge destination PHIs to varying if that's hit.
