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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467

--- Comment #20 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(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?

> 
> > 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.

I see, I should submit that dbgcnt patch. I wrote it just never sent it.