有关使用__builtin_expect的指导原则 [英] guidelines on using __builtin_expect

问题描述

如果包含多个嵌套测试的gcc的 __ builtin_expected 宏> if if 我有这样的代码：

What should I wrap with the gcc's __builtin_expected macros within an if with multiple and nested tests? I have this code:

if((x<RADIUS && (forward?v<0:v>0)) || (x+RADIUS>dimensions[d] && (forward?v>0:v<0)))

我有（可笑地）包裹了我所能做的一切：

I have (ridiculously) wrapped everything I could:

#define likely(x)       __builtin_expect((x),1)
#define unlikely(x)     __builtin_expect((x),0)
if(unlikely(unlikely(unlikely(x<RADIUS) && likely(likely(forward)?likely(v<0):likely(v>0))) || unlikely(unlikely(x+RADIUS>dimensions[d]) && likely(likely(forward)?likely(v>0):likely(v<0)))))

我希望这只是一种矫枉过正，因为它几乎不可读。

I hope it's just an overkill, because it's pretty much unreadable.

推荐答案

我不认为这里有错误的答案。编译器将使用你的提示来决定哪种情况下每次比较都会产生其他情况;这不仅仅是其他的C代码，而且还在逻辑的和和 ors 中，越多的信息越好。

I don't think there's a wrong answer here. The compiler will use your hints to decide which case to make the "else" case of every comparison; that's not just the C code else, but within the ands and ors of the logic also, and the more information the better.

为了可读代码的缘故，我建议把它放在一个很大的东西上：每个if语句一次，但这不是基于任何确凿证据。

For the sake of readable code, I'd suggest keeping it to the big stuff: once for each if statement, but that's not really based on any hard evidence.

您是否考虑过使用 -fprofile-generate ，使用典型数据运行代码，然后使用 -fprofile-use ？这样编译器就可以为所有这些情况构建自己的图片。这是更便携的（没有特定于编译器的注释），更具可读性和更多的未来证明。

Have you considered using -fprofile-generate, run the code with typical data, and then rebuild with -fprofile-use? That way the compiler can build it's own picture for all these cases. This is more portable (no compiler-specific annotations), more readable, and more future proof.

这篇关于有关使用__builtin_expect的指导原则的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！