speculative execution
When a CPU predicts which way a branch will go, it does not just predict — it acts on the prediction, racing ahead to fetch and actually EXECUTE the instructions on the guessed path before it knows whether the guess was right. This running-ahead-on-a-guess is speculative execution. It is the natural partner of branch prediction: prediction picks a path, and speculation does the work down it eagerly, so that if the guess holds, the results are already computed and no time was lost waiting.
Speculation is broader than just branches. A modern out-of-order core speculates in several ways: past branches (executing the predicted side), past possible memory dependencies (assuming a load does not alias an earlier store whose address is not yet known), and more. All of this speculative work is held provisionally in the reorder buffer and is NOT made architecturally visible until the instruction retires. If the speculation turns out correct, those results retire normally and the speculation was a pure win. If it turns out wrong — the branch went the other way, or a dependency was violated — the speculative instructions are squashed: their ROB entries are discarded before retirement, the architectural state is rolled back as if they never ran, and execution restarts on the correct path. From the program's point of view, mis-speculated instructions have no effect on results.
Here is the crucial honesty, and the bridge to security. Although mis-speculated instructions are erased from the architectural (programmer-visible) state, they DID run on the hardware, and they can leave traces in MICROarchitectural state — most importantly, they can pull data into the cache. That residue is observable through timing, even though the values themselves were rolled back. This gap between 'architecturally erased' and 'microarchitecturally left a footprint' is exactly the foundation of Spectre and related speculative-execution attacks: an attacker steers the predictor to speculatively access secret-dependent memory, then measures cache timing to recover the secret. The depth of those attacks belongs to the security field (see spectre-meltdown); what matters here is the mechanism — speculation is a performance technique whose rolled-back work is not perfectly invisible.
if (i < array_len) { x = array[i]; } A core may speculatively execute array[i] before the bounds check resolves. Even if i was out of bounds and the result is squashed, the speculative load can leave a line in cache — the timing residue that Spectre exploits.
Rolled back architecturally, yet a cache footprint remains — the microarchitectural leak behind Spectre.
Mis-speculated instructions have no effect on your program's RESULTS, but they are not free or fully invisible — they consume execution resources and can leave timing-observable cache state, which is precisely why speculation became a security problem, not just a performance one.