Store-to-load forwarding is the CPU's fast path: when a load's address matches an older store still sitting in the store buffer, the CPU forwards the store's data directly to the load without waiting for it to hit L1. This saves 4-5 cycles. But forwarding only works when the store fully covers the load. When it doesn't, you hit a partial store forwarding stall, and the penalty is brutal: 10-20 cycles on Intel, sometimes more.

The rule the hardware enforces: the store must be at least as wide as the load, and the load must be fully contained within the store's byte range. If the load reads bytes the store didn't write — even one byte — forwarding fails. The CPU has to drain the store to L1, then re-issue the load from cache. On some microarchitectures it's even worse: the load waits until the store retires, not just until it commits to cache.

Concrete example. This C code triggers it constantly:

• buf[0] = 0xFF; — 1-byte store
• uint32_t x = *(uint32_t*)buf; — 4-byte load of the same location

The load needs 4 bytes; the store buffer only holds 1 byte of that range. Bytes 1-3 haven't been written yet (or were written by an even older store that already drained). The CPU can't assemble the load's value from mixed sources — the store buffer forwards whole values, not partial ones. Result: the load stalls until the byte store hits L1.

The opposite direction — wide store, narrow load fully contained — does forward cleanly. A 4-byte store followed by a 1-byte load of any byte inside it works fine. It's the narrow-store-wide-load pattern that dies.

Where this bites in real code:

• Union punning: writing a float field then reading the whole uint64_t union — classic stall.
• Serialization/deserialization: writing individual bytes into a buffer then reading them as a word.
• Bitfield writes: the compiler may emit a byte-write when the surrounding struct is later read as a wider type.
• memcpy tail handling: the "handle the last 3 bytes" loop followed by reading the destination as a word.

Rule of thumb. A forwarded store saves ~5 cycles. A failed forward costs ~15. So partial forwarding is roughly 3x worse than no forwarding at all. If you're writing then immediately reading the same memory, either make the store wider than the load, or space them far enough apart that the store drains naturally before the load issues.