[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[segher at gcc dot gnu.org]

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

--- Comment #26 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #25)
> (In reply to Segher Boessenkool from comment #24)
> > Wrt keeping REG_EQUAL notes...  If you want to keep them you need to make
> > sure
> > they still are valid.  GCC keeps those on i3, it is much too hard in general
> > to
> > validate other such notes.
> 
> It seems to be that the REG_EQUAL notes of the SET dests in the final
> instruction we combine into, so 24 for
> 
> Trying 78, 17 -> 24:
> 
> are better always valid even after the combination - at least when they
> are not refering to pseudos set by insns combined (78, 17 here) and always
> when the REG_EQUAL is constant.  When there are multiple sets in the final
> insn (24) then which note ends up where is determined by the SET dests.

In the *resulting* final insn.  And some of those notes may have to be moved
to i2 -- when there are multiple sets in the *resulting* insn, and it is split.

> For this particular case preserving _constant_ REG_EQUAL notes would be
> important.  And for this case only handling single-set would be good enough.

You can *never* require REG_EQUAL notes for correctness.  It is always correct
to delete REG_EQUAL notes.  They exist to make optimisation easier, and for
nothing else.

> Of course if i3 is not always '24' (in this case) then we have to find
> a better place to preserve these than distribute_notes.

Or fix the bug: that which requires REG_EQUAL notes to not be deleted.  This
is a problem whether or not we hide the problem here (by making things
optimised better).