Every push, pop, call, and ret implicitly modifies the stack pointer. A naive CPU would treat each SUB RSP, 8 as a real ALU op: rename it, allocate a physical register, schedule it, execute it, retire it. On tight function-call code that's a dozen wasted micro-ops per frame — and worse, each one creates a serial dependency chain on RSP that stalls every subsequent stack access.

The stack engine is a tiny piece of hardware in the front-end that intercepts stack-pointer arithmetic and folds it away before the renamer ever sees it. Intel added it around Pentium M; AMD did the same in K10. It works by keeping a small stack delta counter that accumulates the net RSP adjustment implied by the recent instruction stream.

• When decode sees push rax, it doesn't emit "sub rsp, 8; store [rsp], rax" as two dependent uops. Instead, it emits one store with an address of rsp + delta and bumps the delta by −8.
• pop, call, ret, and explicit add/sub rsp, imm all just update the delta.
• The renamer never sees a chain of dependent RSP writes — every stack access uses the current architectural RSP plus a decoder-time constant.

The catch: any instruction that reads RSP directly (like mov rax, rsp or lea rax, [rsp+16]) or writes it non-trivially (mov rsp, rax) forces the engine to emit a sync uop: a real add that flushes the accumulated delta into the physical RSP. That sync costs a cycle and creates a dependency. Compilers know this: modern GCC and LLVM avoid mov reg, rsp mid-function precisely because it drains the stack engine.

Concrete example. A leaf function with three pushes, some work, and three pops: on a stack-engine CPU, the six pushes/pops become six memory ops with zero RSP-arithmetic uops in the back-end. On a hypothetical no-stack-engine core, the same code would allocate six ROB entries just for the RSP updates and serialize every load through them.

Rule of thumb. Each stack-engine sync uop costs roughly 1 cycle plus creates a 1-cycle dependency for the next stack access. If a function has N pushes and one lea rax, [rsp+off] before them, you're paying for one sync — cheap. But a mov rbp, rsp prologue followed by mov rsp, rbp epilogue in every function is why -fomit-frame-pointer exists: it deletes two guaranteed syncs per call.