[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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 rguenther@suse.de from comment #19)
> > > Am 23.01.2024 um 18:06 schrieb tnfchris at gcc dot gnu.org <gcc-bugzilla@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.