Modern x86 cores burn a shocking amount of power on the front-end: fetching bytes from L1I, predecoding x86's variable-length instructions, decoding into µops, and steering them into the rename engine. For tight loops that execute the same handful of instructions millions of times, doing all that work every iteration is absurd. The Loop Stream Detector (LSD) is the hardware answer: detect a loop, lock its µops in a small buffer, and shut down everything upstream.

Intel introduced the LSD in Core 2 (Merom, 2006) as an instruction-level buffer. Nehalem moved it after decode so it stored µops directly — bigger win, since decode is the expensive stage. The LSD sits between the µop queue and the renamer, holding ~56–64 µops on Skylake-class cores. When the branch predictor and µop queue notice a backward branch closing a loop that fits in the buffer, the LSD activates: the fetch unit, predecoder, decoders, and µop cache all clock-gate. The renamer drinks straight from the LSD until the loop exits.

Concrete example: a memcpy hot loop on Skylake — load, store, increment, compare, branch — decodes to roughly 5 µops. The LSD streams these from a tiny SRAM at full rename bandwidth (4–5 µops/cycle) while the entire fetch/decode pipeline sits idle. On Intel's own measurements, this saved ~10% front-end power on loop-heavy workloads like crypto and codec inner loops.

The catch — and why this is a recurring CPU-design soap opera — is correctness under microcode updates. In 2019, Intel disabled the LSD via microcode on Skylake/Kaby Lake/Coffee Lake because a bug (erratum SKL150) could cause it to mishandle certain instruction sequences, corrupting register state. Performance dropped a few percent on tight-loop benchmarks overnight. Ice Lake and later got a redesigned LSD that's enabled again. AMD's Zen family uses its µop cache for the same role rather than a separate LSD — different architectural choice for the same workload.

Rule of thumb: if your hot loop's µop count fits in ~64 µops and contains no microcode-assisted instructions (no cpuid, no div on older parts, no near-call/ret stacks that overflow the RAS), it'll stream from the LSD. Use perf stat -e lsd.uops on Linux to measure: a ratio of lsd.uops / uops_issued.any near 1.0 means your loop is essentially free on the front-end.

The LSD is a perfect example of an under-appreciated truth: a huge fraction of modern CPU design is figuring out how to not do work the CPU has already done.