https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #27 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 14 Apr 2022, segher at gcc dot gnu.org wrote: > 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). Then the bug is in combine itself - it places a REG_EH_REGION note but fails to split the basic-block after the affected instruction. Or it even considers placing it on the not last instruction. Maybe there's already the constraint that combine never combines an insns with a REG_EH_REGION note (aka a possibly throwing insn) with another but only combines not throwing insns into a throwing one. Then the correct action is to always place the REG_EH_REGION note on the last insn, or if that cannot throw, throw it away. If we somehow created an intermediate throwing/trapping insn we should then reject the combination. Richard.
