https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127768
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 9 Oct 2026, liuhongt at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127768 > > Hongtao Liu <liuhongt at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |liuhongt at gcc dot gnu.org > > --- Comment #4 from Hongtao Liu <liuhongt at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #3) > > CCed Intel/AMD folks for the optimal strategy to spill/reload - I'm > > specifically thinking about the ability of some uarchs to perform memory > > "renaming" to registers which IIRC is quite constrained as of the memory > > access forms they accept but is specifically targeted for stack > > spills/reloads. The question is for HImode/QImode spills/reloads where we > > seem to (always?) have at least an SImode size spill slot and thus could in > > theory simply spill/reload in SImode. > > I guess spilling in QImode and reloading via movzbl would break renaming? > > According to my experiments on SPR, m8/32 store can be renamed with movzbl m8 > But movzwl m16 can't be remaned with m16/32 store, though it can be STLF. > > So using m32 store should be generally ok for Intel processors. > For m8 movzwl, It remains m8 movzbl renaming > For m16 movzwl, it can't be renamed with either m16/m32, so using m32 won't > hurt. That means for m16 using m32 store and m32 load would be best.
