The kernel's unlikely() macro buys you fall-through, and bills you when you guess wrong

Read the two disassemblies side by side and the mechanism stops being mysterious. In the build using `likely()`, the compare is followed by a `b.eq` that leaves the loop body for a block parked past the loop's exit branch, and that block ends with an unconditional jump back to the counter increment ^[10]. In the build using `unlikely()`, the same compare becomes a `b.ne` to the rare block, and the common body sits inline immediately after the not-taken branch ^[11]. The arithmetic is identical. What the annotation bought was the answer to one question: which side of the branch gets to fall through.

That makes the cost of a wrong answer countable. The mis-annotated loop's common path carries two extra taken control transfers per iteration, the conditional jump out to the relocated block and the unconditional jump back ^[12], and with the modulus at 1000 that path runs 99.9% of the time ^[6]. Call it a little under two million extra taken jumps for every million iterations ^[13]. The 0.1% case, the one the programmer told the compiler to favour, gets the inline body it did not need.

This is why the macro belongs downstream of a profile rather than in muscle memory. The direction of the effect is set entirely by a runtime frequency the compiler cannot see, and the author's own result is that the hint degrades as the annotated branch gets rarer ^[8]. The definition itself is honest about how little is being said: `unlikely(e)` is `__builtin_expect(!!(e), 0)` ^[2], and `__builtin_expect` does nothing but assert that an expression's value will equal the second argument ^[3]. It is a claim about your workload, worth exactly as much as the measurement behind it. The pattern is all over the Linux kernel ^[1], which is the reason it gets copied and the reason copying is risky: the macro travels between codebases, and the frequency data that justified it does not.

Two limits on how far to carry the numbers. The article names `gcc -O2` as the command ^[9], but the mnemonics and registers in the listing are AArch64 ^[14], so this is one instruction set and one compiler configuration, on branch bodies consisting of a single add ^[5]. And the text asserts worse performance for the bad hint without printing a single timing figure ^[15], so what a reader can actually verify here is the block reordering, not its magnitude on their own hardware. That split is the useful takeaway: the layout change is deterministic and inspectable in the object file, while the cycle cost depends on a predictor you are not being shown. If you are going to spend a hint, spend it where you have counted, and then check the disassembly to see which side ended up inline.