https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> --- > 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. > I guess if it's just going to disabled it then wouldn't it better to just > always pick the latch exit rather than trying to do the whole analysis thing > and maybe pick another exit while the main exit would have worked. The point was to quickly see whether a peeled early exit vectorization is the issue here.
