https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77844
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |compile-time-hog
CC| |aoliva at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
Component|middle-end |rtl-optimization
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's fast with -fno-var-tracking. We have lots of cse-lim stuff in test()
which gets down to a single BB with lots of DEBUG stmts (mostly resets). I
suspect a previous missed optimization became "latent" again (optimizing to a
single BB again). And we're running into one of the var-tracking limits (on
expr depth I assume).
Interestingly with max-vartrack-size == 1 we still run into the compile-time
isse.
I suppose the data-flow problem doesn't converge.
