是否有编译器提示GCC强制分支预测始终遵循某种方式？

对于Intel体系结构，是否有一种方法可以指示GCC编译器生成代码，该代码始终在我的代码中以特定方式强制执行分支预测？英特尔硬件是否还支持此功能？那其他编译器或硬件呢？

我会在C ++代码中使用此代码，因为我知道我希望快速运行的情况，并且即使在最近采用了另一个分支的情况下，也不必关心速度的降低。

for (;;) {
  if (normal) { // How to tell compiler to always branch predict true value?
    doSomethingNormal();
  } else {
    exceptionalCase();
  }
}

作为对Evdzhan Mustafa的后续问题，提示是否可以仅在处理器第一次遇到指令时指定提示，所有后续分支预测均正常运行？

从C ++ 20开始，应将可能和不太可能的属性标准化，并已在g ++ 9中支持。因此，作为讨论在这里，你可以写

if (a>b) {
  /* code you expect to run often */
  [[likely]] /* last statement */
}

例如，在以下代码中，由于if块中的else块，所以可以内联了else [[unlikely]]块

int oftendone( int a, int b );
int rarelydone( int a, int b );
int finaltrafo( int );

int divides( int number, int prime ) {
  int almostreturnvalue;
  if ( ( number % prime ) == 0 ) {
    auto k                         = rarelydone( number, prime );
    auto l                         = rarelydone( number, k );
    [[unlikely]] almostreturnvalue = rarelydone( k, l );
  } else {
    auto a            = oftendone( number, prime );
    almostreturnvalue = oftendone( a, a );
  }
  return finaltrafo( almostreturnvalue );
}

Godbolt链接，比较属性的存在/不存在

GCC支持__builtin_expect(long exp, long c)提供这种功能的功能。您可以在此处查看文档。

exp条件在哪里，c是期望值。例如，如果您想要

if (__builtin_expect(normal, 1))

由于语法笨拙，通常通过定义两个自定义宏（例如

#define likely(x)    __builtin_expect (!!(x), 1)
#define unlikely(x)  __builtin_expect (!!(x), 0)

只是为了减轻任务。

注意：

1. 这是非标准的
2. 编译器/ cpu分支预测器在决定此类事情方面可能比您更熟练，因此这可能是过早的微优化

gcc具有long __builtin_expect（long exp，long c）（重点是我的）：

您可以使用__builtin_expect为编译器提供分支预测信息。通常，您应该更喜欢为此（-fprofile-arcs）使用实际的配置文件反馈，因为众所周知，程序员在预测其程序的实际执行方式方面很差。但是，在某些应用程序中很难收集此数据。

返回值是exp的值，它应该是整数表达式。内置的语义是期望exp == c。例如：

if (__builtin_expect (x, 0))
   foo ();

表示我们不希望调用foo，因为我们希望x为零。由于限于exp的整数表达式，因此应使用诸如

if (__builtin_expect (ptr != NULL, 1))
   foo (*ptr);

测试指针或浮点值时。

如文档所述，您应该更喜欢使用实际的配置文件反馈，并且本文显示了一个实际的示例，以及在这种情况下，它至少最终是对使用的改进__builtin_expect。另请参阅如何在g ++中使用配置文件引导的优化？。

我们还可以找到有关使用此功能的内核宏possible（）和可能性不大的Linux内核新手文章：

#define likely(x)       __builtin_expect(!!(x), 1)
#define unlikely(x)     __builtin_expect(!!(x), 0)

注意!!宏中使用的，我们可以在为什么用!!（condition）而不是（condition）中找到对此的解释。。

仅仅因为该技术已在Linux内核中使用并不意味着使用它总是有意义的。从这个问题我们可以看到，我最近回答了将参数作为编译时间常数或变量传递时函数性能之间的差异，这是许多手动优化技术在一般情况下不起作用的。我们需要仔细分析代码，以了解一种技术是否有效。许多旧技术甚至可能与现代编译器优化无关。

注意，尽管内置不是可移植的 clang也支持__builtin_expect。

同样，在某些体系结构上，可能没有什么不同。

不，那里没有。（至少在现代x86处理器上。）

__builtin_expect其他答案中提到的内容会影响gcc安排汇编代码的方式。它不会直接影响CPU的分支预测器。当然，对代码进行重新排序将对分支预测产生间接影响。但是在现代的x86处理器上，没有指令告诉CPU“假定已/未采用此分支”。

请参阅此问题以获取更多详细信息：实际使用过Intel x86 0x2E / 0x3E前缀分支预测吗？

要清楚，__builtin_expect和/或使用-fprofile-arcs 可以提高代码的性能，既可以通过代码布局为分支预测器提供提示（请参阅x86-64程序集的性能优化-对齐和分支预测），也可以改善缓存行为通过使“不太可能”的代码远离“可能”代码。

在C ++ 11中定义可能/不太可能的宏的正确方法如下：

#define LIKELY(condition) __builtin_expect(static_cast<bool>(condition), 1)
#define UNLIKELY(condition) __builtin_expect(static_cast<bool>(condition), 0)

不同于[[likely]]，此方法与所有C ++版本兼容，但依赖于非标准扩展__builtin_expect。

当这些宏以这种方式定义时：

#define LIKELY(condition) __builtin_expect(!!(condition), 1)

这可能会更改if语句的含义并破坏代码。考虑以下代码：

#include <iostream>

struct A
{
    explicit operator bool() const { return true; }
    operator int() const { return 0; }
};

#define LIKELY(condition) __builtin_expect((condition), 1)

int main() {
    A a;
    if(a)
        std::cout << "if(a) is true\n";
    if(LIKELY(a))
        std::cout << "if(LIKELY(a)) is true\n";
    else
        std::cout << "if(LIKELY(a)) is false\n";
}

及其输出：

if(a) is true
if(LIKELY(a)) is false

如您所见，LIKELY的定义!!用作强制转换来bool破坏的语义if。

这里的关键不在于operator int()并且operator bool()应该是相关的。这是个好习惯。

而是使用!!(x)而不是static_cast<bool>(x)丢失C ++ 11上下文转换的上下文。

由于其他答案均已得到充分建议，因此您可以使用 __builtin_expect来向编译器提供有关如何安排汇编代码的提示。正如官方文档指出的那样，在大多数情况下，内置于您大脑中的汇编程序不如GCC团队设计的汇编程序好。始终最好使用实际的配置文件数据来优化代码，而不是猜测。

类似的但尚未提及的是一种特定于GCC的方式，它强制编译器在“冷”路径上生成代码。这涉及使用noinline和cold属性，它们确实像听起来一样。这些属性只能应用于函数，但是在C ++ 11中，您可以声明内联lambda函数，并且这两个属性也可以应用于lambda函数。

尽管这仍然属于微优化的一般类别，因此标准建议适用（请不要猜测），我觉得它比有用__builtin_expect。几乎没有任何一代的x86处理器使用分支预测提示（参考），因此，无论如何，唯一会影响的是汇编代码的顺序。由于您知道什么是错误处理或“边缘情况”代码，因此可以使用此批注来确保编译器永远不会预测到它的分支，并且在优化大小时会将其与“热门”代码链接起来。

用法示例：

void FooTheBar(void* pFoo)
{
    if (pFoo == nullptr)
    {
        // Oh no! A null pointer is an error, but maybe this is a public-facing
        // function, so we have to be prepared for anything. Yet, we don't want
        // the error-handling code to fill up the instruction cache, so we will
        // force it out-of-line and onto a "cold" path.
        [&]() __attribute__((noinline,cold)) {
            HandleError(...);
        }();
    }

    // Do normal stuff
    ⋮
}

更好的是，GCC会自动忽略它，而在有配置文件反馈时（例如，使用进行编译时-fprofile-use）会使用配置文件反馈。

请参阅此处的官方文档：https : //gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

__builtin_expect可用于告诉编译器您希望分支前进的方式。这会影响代码的生成方式。典型的处理器顺序地运行代码会更快。所以如果你写

if (__builtin_expect (x == 0, 0)) ++count;
if (__builtin_expect (y == 0, 0)) ++count;
if (__builtin_expect (z == 0, 0)) ++count;

编译器将生成类似

if (x == 0) goto if1;
back1: if (y == 0) goto if2;
back2: if (z == 0) goto if3;
back3: ;
...
if1: ++count; goto back1;
if2: ++count; goto back2;
if3: ++count; goto back3;

如果您的提示正确，这将在不实际执行任何分支的情况下执行代码。它比正常序列运行得更快，在正常序列中，每个if语句将在条件代码周围分支并执行三个分支。

较新的x86处理器对预期采用的分支或预期不采用的分支具有指令（有指令前缀；不确定细节）。不知道处理器是否使用它。它不是很有用，因为分支预测可以很好地解决这一问题。因此，我认为您实际上无法影响分支预测。

关于OP，不，在GCC中没有办法告诉处理器始终假定分支已被采用或未被采用。您拥有的是__builtin_expect，它可以完成别人所说的事情。此外，我认为您不想告诉处理器分支是否总是使用。当今的处理器（例如英特尔架构）可以识别相当复杂的模式并有效地进行调整。

但是，有时您想控制默认情况下是否预测会发生分支：如果您知道分支统计信息的代码将称为“冷”。

一个具体的示例：异常管理代码。根据定义，管理代码会异常地发生，但是也许当它发生时，就需要最大的性能（可能存在严重的错误，需要尽快解决），因此您可能希望控制默认的预测。

另一个示例：您可以对输入进行分类，然后跳入处理分类结果的代码。如果分类很多，则处理器可能会收集统计信息，但会丢失统计信息，因为同一分类不会足够快地发生，并且预测资源专用于最近调用的代码。我希望能有一个原始的方式告诉处理器“请不要将预测资源用于此代码”，有时您会说“请勿缓存此代码”。