Stack operations dominate function-heavy code. Every call pushes a return address, every prologue pushes callee-saved registers, every local variable lives at [rsp+N]. If each of these went through the load/store pipeline and L1 cache, even with perfect hits you'd burn 4-5 cycles per access and clog the load/store queue. Modern CPUs cheat: they treat the stack as a small set of internal registers.

The mechanism is stack engine plus memory renaming. The stack engine, sitting in the front-end, watches push, pop, call, and ret. It maintains a speculative rsp delta so back-to-back pushes don't serialize on rsp updates — the renamer can issue them in parallel. Then memory renaming kicks in: when a push rax is followed shortly by pop rbx at the same offset, the CPU recognizes that rbx should just be a copy of rax. It renames the destination to the same physical register, skipping the store, skipping the load, skipping the cache.

Concrete example. Intel's Sandy Bridge introduced the stack engine; Ice Lake extended memory renaming to cover most stack-relative load/store pairs. Consider a function prologue:

• push rbp — store to [rsp-8], decrement rsp
• mov rbp, rsp
• ...body...
• pop rbp — load from [rsp], increment rsp

Without renaming: the pop must wait for the push's store to drain into the store buffer, then either forward through store-to-load forwarding (5 cycles) or hit L1 (4 cycles). With memory renaming, the pop retrieves rbp in zero cycles — it's just a rename map update. Agner Fog's measurements show stack-renamed pops achieving 0-1 cycle effective latency versus 5 cycles for forwarded loads.

Rule of thumb. The renamer handles roughly 16-32 in-flight stack slots. If your function spills 40+ values to stack inside a loop, you blow past the tracking window and pay the full load-store cost. The fix: reduce register pressure (smaller loop bodies, fewer simultaneous live values) or convince the compiler to keep hot values in registers via __attribute__((hot)) or PGO.

This is also why red zone usage in the System V ABI (128 bytes below rsp) is so cheap — leaf functions hit memory-renamed slots that never touch L1. Compilers know this and aggressively reuse the red zone for short-lived spills.