I came across a #define
in which they use __builtin_expect
.
The documentation says:
Built-in Function:
long __builtin_expect (long exp, long c)
You may use
__builtin_expect
to provide the compiler with branch prediction information. In general, you should prefer to use actual profile feedback for this (-fprofile-arcs
), as programmers are notoriously bad at predicting how their programs actually perform. However, there are applications in which this data is hard to collect.The return value is the value of
exp
, which should be an integral expression. The semantics of the built-in are that it is expected thatexp == c
. For example:if (__builtin_expect (x, 0)) foo ();
would indicate that we do not expect to call
foo
, since we expectx
to be zero.
So why not directly use:
if (x)
foo ();
instead of the complicated syntax with __builtin_expect
?
Imagine the assembly code that would be generated from:
if (__builtin_expect(x, 0)) {
foo();
...
} else {
bar();
...
}
I guess it should be something like:
cmp $x, 0
jne _foo
_bar:
call bar
...
jmp after_if
_foo:
call foo
...
after_if:
You can see that the instructions are arranged in such an order that the bar
case precedes the foo
case (as opposed to the C code). This can utilise the CPU pipeline better, since a jump thrashes the already fetched instructions.
Before the jump is executed, the instructions below it (the bar
case) are pushed to the pipeline. Since the foo
case is unlikely, jumping too is unlikely, hence thrashing the pipeline is unlikely.