我碰到了一个#define他们用的__builtin_expect。
#define
__builtin_expect
该文件说:
内置功能: long __builtin_expect (long exp, long c) 您可以__builtin_expect用来向编译器提供分支预测信息。通常,您应该更喜欢为此(-fprofile- arcs)使用实际的配置文件反馈,因为众所周知,程序员在预测其程序的实际执行效果方面很差。但是,在有些应用程序中很难收集此数据。 返回值是的值exp,应为整数表达式。内置的语义是预期的 exp == c。例如: if (__builtin_expect (x, 0)) foo (); 表示我们不希望调用foo,因为我们希望x为零。
long __builtin_expect (long exp, long c)
您可以__builtin_expect用来向编译器提供分支预测信息。通常,您应该更喜欢为此(-fprofile- arcs)使用实际的配置文件反馈,因为众所周知,程序员在预测其程序的实际执行效果方面很差。但是,在有些应用程序中很难收集此数据。
-fprofile- arcs
返回值是的值exp,应为整数表达式。内置的语义是预期的 exp == c。例如:
exp
exp == c
if (__builtin_expect (x, 0)) foo ();
表示我们不希望调用foo,因为我们希望x为零。
foo
x
那么为什么不直接使用:
if (x) foo ();
而不是复杂的语法__builtin_expect?
想象一下将由以下代码生成的汇编代码:
if (__builtin_expect(x, 0)) { foo(); ... } else { bar(); ... }
我想应该是这样的:
cmp $x, 0 jne _foo _bar: call bar ... jmp after_if _foo: call foo ... after_if:
您可以看到,指令的排列顺序是bar大小写先于foo大小写(与C代码相对)。这可以更好地利用CPU管线,因为跳转会破坏已经获取的指令。
bar
在执行跳转之前,将其下面的指令(bar案例)推送到管道中。由于foo情况不太可能发生,因此也不太可能发生跳跃,因此不太可能对管道造成破坏。