Every floating-point instruction on x86 has a dirty secret: it doesn't just produce a result. It also updates a shared status word — MXCSR on x86, FPCR/FPSR on ARM — that records whether the operation was inexact, underflowed, overflowed, divided by zero, or hit an invalid operand. That status word is a single architectural resource, and every FP op in flight is a potential writer to it. That's a serialization hazard hiding inside code that looks embarrassingly parallel.

Naively, this would kill out-of-order execution. If instruction N+1 has to see the flags produced by instruction N, you've just serialized the entire FP pipeline through a one-bit-wide bottleneck. So CPUs cheat, hard:

• Flag prediction: the CPU speculates that no exception flag will be raised (the common case) and lets instructions retire without waiting.
• Sticky-flag OR trees: MXCSR exception bits are "sticky" — once set, they stay set until software clears them. So the hardware can OR results in at retirement without preserving order.
• Rename the whole thing: some designs (Apple's cores, recent AMD Zen) rename MXCSR the way integer flags get renamed, so reads and writes don't false-dependency each other.

The cheat breaks down when software actually reads MXCSR. A STMXCSR or fetestexcept() call forces the CPU to drain every in-flight FP op, merge all their exception bits, and hand you a coherent snapshot. On Skylake this is roughly a 20–30 cycle stall, and worse on wider cores where more FP ops are in flight.

Concrete example: a numerical library that calls fetestexcept(FE_INEXACT) after every batch of operations to check for precision loss. Author saw a 4× slowdown vs. the version that only checked once at the end. The per-batch check drained the FP pipeline over and over — the actual math was fine, the flag read was the killer. Removing it and checking only at loop exit restored full throughput.

Rule of thumb: touching MXCSR (reading it, writing it, changing rounding mode) costs roughly 1 full FP pipeline drain — call it 20–50 cycles depending on core width. Changing rounding modes inside a hot loop is one of the classic ways to accidentally serialize floating-point code. If you need directed rounding, use the AVX-512 {rn-sae}-style embedded rounding hints instead — they're per-instruction and don't touch MXCSR at all.