https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> --- So (haven't tried that yet though) guarding either Segher's change (what is in trunk) or Richi's instead on the DF_INSN_LUID distance between i2 and i3? Behave like vanilla GCC 14 if it is only a couple of instructions (couple of dozens, whatever) and do the new behavior (punt on the two insn combination altogether if i2 didn't change or just don't rewalk links) if the distance is too large and we'd run into the PR101523 issues? Because as this PR shows, those 2->2 insn merges with no change on i2 can make a lot of sense and allow combination on the second and following user of i2 dest which current trunk just punts on.
