https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72772
--- Comment #6 from amker at gcc dot gnu.org --- (In reply to Richard Biener from comment #5) > Ok, so we record a correct upper bound for a loop but then later thread1 > makes > a mess of the loop structures, introducing multiple back-edges by mashing > an outer loop of said loop into it, making the number of iteration upper > bound obviously incorrect. > > And it is CFG cleanup which introduces those multiple back-edges, mashing > the two loops! It does this by treating the outer loop header as > "forwarder". > > Now we could detect this situation in redirect_edge_and_branch or avoid this > loop smashing (in the end loop init will disambiguate the latches again if > requested, re-creating the outer loop). I think we at least want such > smashing late (more aggressive cleanup was introduced because otherwise > we create worse initial RTL and assembler). > > The issue is how to detect this reliably in redirect_edge_and_branch given > it has to work when LOOPS_NEED_FIXUP is set ... we have to reset niter > info and estimates / upper bound whenever we redirect a latch - of both > the source and destination loop. With LOOPS_NEED_FIXUP we only can rely > on headers (well, not even that, and all other cfghook loop fixup stuff > has a similar issue). The other option is to simply wipe niter info whenever > we fixup loops (loop fixup is unfortunately a global thing). > > I believe I saw this issue on another PR as well. OTOH, I noticed that (at least) several optimizers rely on bound information passed along in compilation flow. And it's hard to get accurate bound information by niter analyzer itself, for example, vectorized loops generally have parameterized start/end condition values.
