https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 11 Mar 2025, jakub at gcc dot gnu.org wrote: > 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? That sounds at least more reasonable than allowing N combinations unrestricted before applying some limit. Ideally the iteration had an extra worklist we'd just put those interesting insns on (it should be LUID ordered of course).
