Hacker News Reader

Comment by notum | Hacker News Reader

Do [[likely]] and [[unlikely]] flags have anything to do with CPU code prediction / speculative execution that has been a burning subject recently (Spectre)?

View on HN

Not really. They're hints to the complier about how to order the code for 'if..else' statements.

> They're hints to the complier about how to order the code for 'if..else' statements.

It's more than that - it can inform many optimisations, for example keeping values alive in one branch at the expense of another.

No, they are intended for helping with performance (letting the compiler know which branch of execution should it make the "default" for the CPU).

But see "Don’t use the [[likely]] or [[unlikely]] attributes": https://blog.aaronballman.com/2020/08/dont-use-the-likely-or...

Not directly. It signals that the compiler does well when optimizing the [[likely]] path at the expense of making the other paths less optimized.

IIUC, the optimisation is the same, but all it does is tell the compiler what the hot path is likely to be and so the code won't 'jmp' to it; the instructions are likely to be in I-cache.

gcc (maybe other compilers too) can put the cold path to a separate section, so it further improves happy-path code cache locality.

Not really.. in part 1 of a hypothetical spectre attack, you’d have to figure out how to time a branch hit/miss, and the presence of likely may change the times/inputs you’d need to use to do that.

These attributes are just hints to move hot/slow code near/far away and to maybe to the right thing if there’s no branch prediction. They cannot prevent speculative execution.

it's a standard version of e.g. GCC and Clang's __builtin_expect

Reply on news.ycombinator.com