https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #21 from Andreas Krebbel <krebbel at gcc dot gnu.org> --- (In reply to Segher Boessenkool from comment #16) ... > When some insns have changed (or might have changed, combine does not always > know > the details), combinations of the insn with later insns are tried again. > Sometimes > this finds new combination opportunities. > > Not retrying combinations after one of the insns has changed would be a > regression. Wouldn't it in this particular case be possible to recognize already in try_combine that separating the move out of the parallel cannot lead to additional optimization opportunities? To me it looks like we are just recreating the situation we had before merging the INSNs into a parallel. Is there a situation where this could lead to any improvement in the end?
