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

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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

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