Why Flush Speculative State on Branch Misprediction?

When a modern processor encounters a conditional branch, it often predicts the outcome and executes instructions along the predicted path before knowing whether the guess is right. If the prediction turns out to be wrong, all speculative execution state from that incorrect path must be completely flushed. Failing to discard this state would corrupt program correctness, violate sequential execution semantics, and leave the processor with invalid data in its registers, memory buffers, and pipeline stages.

Maintaining Program Correctness

Classical computing relies on the illusion of sequential execution, where instructions appear to complete one after another in program order. Speculative execution breaks this order internally to keep execution units busy and hide memory or branch latency. When a branch is mispredicted, the instructions fetched and executed after the branch belong to a path that should never have been taken according to the program's control flow.

If any results from those mispredicted instructions were allowed to commit to architectural state—such as the architectural register file or main memory—the program would compute wrong values, take unintended side effects, or crash. Flushing ensures that only instructions on the true execution path ever become visible to the rest of the system.

Hardware Structures That Must Be Cleared

To recover cleanly from a misprediction, the processor must roll back several microarchitectural structures that hold speculative state:

• Pipeline Registers and Instruction Queues: Instructions from the wrong path sitting in fetch, decode, or issue queues must be squashed so they never reach execution or commit.
• Reorder Buffer (ROB): The ROB tracks instructions in program order and holds their speculative results until they are safe to commit. On a misprediction, all entries younger than the mispredicted branch are invalidated.
• Register Alias Table (RAT) and Physical Registers: Out-of-order processors rename architectural registers to physical registers. The speculative register mappings created after the branch must be reverted to the last known good checkpoint, and the allocated physical registers must be freed.
• Load/Store Queues (LSQ): Speculative stores buffered in the store queue must be discarded so they are never written to the cache or memory. Speculative loads that may have forwarded data from those stores must also be invalidated.

Preventing Cascading Errors

Even if a mispredicted instruction does not directly write to memory, leaving its partial state in the pipeline can cause subtle, cascading failures. For example, a stale register mapping in the RAT could cause a subsequent, valid instruction from the correct path to read a garbage value. Similarly, an unpurged entry in the load/store queue could trigger false memory dependency violations or forward incorrect data to later loads.

A complete flush guarantees a clean slate at the branch boundary, allowing the front end to redirect to the correct target address and resume fetching without interference from leftover speculative work.

The Performance Trade-off

Flushing the pipeline is expensive because it discards completed work and introduces a recovery penalty—often called the branch misprediction penalty—measured in clock cycles. However, this cost is necessary to preserve exactness. Modern processors minimize how often flushes happen by using sophisticated branch predictors, and they reduce the cost of a flush by checkpointing register mappings at branches so recovery can happen in just a few cycles.