When a load executes out-of-order, it gambles that no older store — one earlier in program order but not yet executed — will write to the same address. The load queue (LQ) holds every in-flight load along with its computed address, and every store that resolves its address has to CAM-search the LQ to find younger loads that already speculatively read the same bytes. If it finds one, that load and everything dependent on it must be squashed and replayed. This is memory ordering violation detection, and it's one of the most expensive structures in the core.

The reason this exists: store addresses often resolve after younger loads execute. A load can't wait for every older store to compute its address — that would serialize memory entirely. So the CPU lets loads fly ahead, records their addresses in the LQ, and patches things up if a store later collides. The LQ entry holds the physical address, the size, the load's ROB tag, and a "executed speculatively" bit.

The cost of the CAM: every store-address resolution searches N load queue entries in parallel. Skylake's LQ holds 72 entries; Golden Cove pushed it to 192. Doubling the LQ doubles the CAM width, which scales power roughly quadratically because every entry compares against every store broadcast. This is why LQs grow more slowly than ROBs — you can have a 512-entry ROB with only a 192-entry LQ, because not every in-flight instruction is a load.

Concrete example. Consider this loop iterating a linked list:

• store [r1+8], r2 — address resolves slowly because r1 came from a cache miss
• load r3, [r4+0] — executes immediately, r4 was ready

If r1+8 and r4+0 turn out to be the same address, the load read stale data. When the store address finally resolves, the LQ CAM finds the younger load, flags it, and the pipeline flushes everything from that load onward — typically 15–20 cycles of wasted work. A memory dependence predictor (covered earlier) tries to prevent this by stalling the load, but when it's wrong, the LQ is the safety net.

Rule of thumb: the LQ effectively caps your memory-level parallelism. If 30% of your instructions are loads and you want a 200-instruction window, you need at least 60 LQ entries. Run out of LQ slots and dispatch stalls — even if the ROB has room. perf stat -e ld_blocks.no_sr on Intel exposes this stall directly.