https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Tamar Christina from comment #20) > (In reply to rguent...@suse.de from comment #19) > > > Am 23.01.2024 um 18:06 schrieb tnfchris at gcc dot gnu.org > > > <gcc-bugzi...@gcc.gnu.org>: > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467 > > > > > > --- Comment #18 from Tamar Christina <tnfchris at gcc dot gnu.org> --- > > > (In reply to Richard Biener from comment #7) > > >> I do wonder whether LOOP_VINFO_EARLY_BREAKS_VECT_PEELED actually works > > >> (since > > >> without early exits we cannot handle a non-empty latch because of > > >> correctness > > >> issues). I'd very much have preferred to deal with these by loop > > >> rotation > > >> (there's the loop_ch pass). We're still doing this, even when > > >> LOOP_VINFO_EARLY_BREAKS_VECT_PEELED: > > >> > > >> /* We assume that the loop exit condition is at the end of the loop. > > >> i.e, > > >> that the loop is represented as a do-while (with a proper if-guard > > >> before the loop if needed), where the loop header contains all the > > >> executable statements, and the latch is empty. */ > > >> if (!empty_block_p (loop->latch) > > >> || !gimple_seq_empty_p (phi_nodes (loop->latch))) > > >> return opt_result::failure_at (vect_location, > > >> "not vectorized: latch block not > > >> empty.\n"); > > >> > > >> so that's a bit odd (but loop_ch tries to ensure the latch is empty > > >> anyway). > > >> > > >> Does the following fix the issue? > > > > > > Not really sure I understand what the latch being empty has to do with > > > LOOP_VINFO_EARLY_BREAKS_VECT_PEELED as the latch is still empty even with > > > it. > > > > The latch is everything after the IV exit. > > Wait, are you saying, that conceptually if we pick an earlier exit as the > main exit then for the vectorizer the "latch" is everything below the fall > through edge? > > i.e. that the "latch" then contains the normal loop exit? Yes. The reason the latch has (had) to be empty is that if there's any side-effects in it we wouldn't treat them correctly for the last vector iteration, since we'd prematurely exit the loop for it. So I wondered if the support for "peeled" early exits really would have made this restriction obsolete iff it were not restricted to multi-exit loops and iff the solution is that "easy" why we didn't chose to implement this before - so a way (at least for debugging) to disable the "peeled" case (which I think is also worse for performance than rotating the loop) would be nice. That said, for GCC 15 it would be nice to try to generalize this support to single-exit loops and relax the empty latch restriction.
