https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127768
vekumar at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vekumar at gcc dot gnu.org
--- Comment #6 from vekumar 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?
As per my experiments on AMD targets, loads of the form movzbl, movzwl,
movsbl and movswl are not renamed. The reload goes through store-to-load
forwarding, whether the spill was m8/m16 or m32.
A plain m32 load after an m32 store is renamed. A reload folded into an add
(e.g. addw m16,%ax / addb m8,%al) is also renamed, whether the store was
m8/m16 or m32.
So, for m8/m16 spills, an m32 store plus an m32 reload is best. If the value
needs extending, extend it in a register after the reload.
