https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126963
--- Comment #4 from Drea Pinski <pinskia at gcc dot gnu.org> --- (In reply to [email protected] from comment #3) > On Thu, 20 Aug 2026, jmelcr at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126963 > > > > --- Comment #2 from Josef Melcr <jmelcr at gcc dot gnu.org> --- > > Yes, I verified the bisection before submitting the bug and ran it again > > just > > now, it does slow down. This lbm graph seems to be stable, though lbm can be > > pretty noisy. Could just be random changes slowing it down I guess? > > Possibly. At least it does hint at that the particular change of > copy-propagation causes downstream code generation changes (the > copy would not have prevailed for long even before the change). One thing it could be ssa name differences causing to expand slightly different which later on brings RA differences. With lbm having high register pressure in the inner most loops; it might be something spilling that it was not before and something else being kept in a register and that causes a performance difference.
