https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #46 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 16 Sep 2025, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 > > --- Comment #45 from Andrew Pinski <pinskia at gcc dot gnu.org> --- > (In reply to Andrew Pinski from comment #2) > > (In reply to Jan Hubicka from comment #0) > > > saving an instruction. Why we do not move stack+8 updating out of the > > > loop? > > > > Maybe because of a clobber: > > cur$second_5 = MEM[(const struct pairD.26349 &)_7 + > > 18446744073709551608].secondD.27577; > > # PT = nonlocal escaped > > _4 = _7 + 18446744073709551608; > > # .MEM_9 = VDEF <.MEM_1> > > stackD.26352.D.27437._M_implD.26667.D.26744._M_finishD.26670 = _4; > > # .MEM_10 = VDEF <.MEM_9> > > MEM[(struct pairD.26349 *)_7 + -8B] ={v} {CLOBBER}; > > The clobber definitely is NOT helping. If we do `-fno-exceptions -O2 > -flifetime-dse=0` LIM can pull the store out. There's a bug about LIM (store-motion) and clobbers already. IIRC I had a patch (attached?) that moves the clobber as well as part of the store motion rewrite. Maybe this isn't working here for $reason, likely that the clobber LHS and the other "store" isn't analyzed as the same memory reference or so. I'll have a short look.
