The Compiler Reordered It Before the CPU Did

The compiler operates under an *as-if* rule: it may perform any transformation provided the program behaves as if it had executed according to the language's abstract machine. Crucially, "behaves as if" is defined in terms of a specific list of observable effects — typically I/O, volatile accesses and synchronisation — and *not* in terms of which instructions exist or what order they appear in. Everything not on that list is fair game.

The processor then operates under the architecture's memory model, which is a different and generally weaker contract. It guarantees that a *single* thread observes its own operations as if in program order, and makes much narrower promises about what other threads see and when (Hardware Memory Models Are Not Language Memory Models). Within a thread it will happily execute instructions as their operands become ready rather than in sequence (Out-of-Order Execution).

These layers are independent. A barrier that constrains the CPU does not constrain the compiler, and a compiler barrier does not constrain the CPU. This is precisely why language-level atomics exist: a memory_order annotation has to emit both the right machine instruction *and* prevent the compiler from moving things across it. Getting one and not the other produces code that works under -O0 and breaks under -O2, or works on x86-64 and breaks on AArch64.

The list is longer than most people expect. It may hoist a loop-invariant computation out entirely, keep a variable in a register and never write it to memory, unroll the loop, vectorize it (Auto-Vectorization: Verify, Do Not Assume), fuse two loops into one or split one into two, replace a multiply with shifts, evaluate a constant expression at compile time — and delete code whose result is never observed, which is the transformation that silently destroys naive microbenchmarks (Every Way a CPU Microbenchmark Lies).

What it may *not* do is change observable behaviour as the language defines it. The subtlety is that the language's definition is narrower than intuition: the time a loop takes is not observable, so a loop with no observable effect may be removed. Reading an uninitialised value or overflowing a signed integer may be undefined, in which case the compiler is entitled to assume it never happens and optimise on that basis — which is how a bounds check can legally vanish.

The practical consequence is that source-level operation counting predicts neither the instruction count nor the cost. The only reliable way to know what the machine will run is to look at what the compiler emitted, which is a routine and underused activity: modern toolchains make the generated assembly easy to inspect, and reading it settles arguments that speculation cannot.

The three recurring failures are worth naming. Microbenchmarks that measure nothing: the timed loop computes a value the program never uses, the compiler deletes it, and the benchmark reports an impossibly fast result. Concurrency bugs that appear only under optimisation: a flag polled in a loop without an atomic or volatile annotation gets hoisted into a register, and the thread never sees the update. Portability failures: code that relies on x86-64's relatively strong ordering breaks on AArch64, which permits more reordering — the bug was always there, and the stronger hardware was hiding it (Why Your Loads and Stores Happen Out of Order).

The unifying diagnosis is that in each case the programmer had a contract in mind that the language did not actually provide. The fix is never to guess harder; it is to state the requirement in terms the compiler understands — an atomic with the ordering you need, a volatile for a memory-mapped register, a compiler barrier, or consuming the benchmark result so it cannot be deleted.

None of this is an argument against optimisation, and it is emphatically not an argument for writing assembly. The compiler is better at instruction selection and scheduling than almost anyone, and its transformations are why high-level code performs at all. The argument is only that it is a *transformation layer with rules*, and knowing the rules is what lets you predict its output and debug its results.