我可以在 C 中将 GCC 的 __builtin_expect() 与三元运算符一起使用吗

The 海湾合作委员会手册 http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html仅显示 __builtin_expect() 放置在“if”语句的整个条件周围的示例。

我还注意到，如果我使用它，例如，与三元运算符一起使用，或者在任何任意整数表达式中使用它，GCC 不会抱怨，即使是不在分支上下文中使用的表达式。

所以，我想知道它的使用的根本限制到底是什么。

当用于这样的三元运算时，它会保留其效果吗：

int foo(int i)
{
  return __builtin_expect(i == 7, 1) ? 100 : 200;
}

那么这个案例呢：

int foo(int i)
{
  return __builtin_expect(i, 7) == 7 ? 100 : 200;
}

和这个：

int foo(int i)
{
  int j = __builtin_expect(i, 7);
  return j == 7 ? 100 : 200;
}

它显然适用于三元和常规 if 语句。

首先，我们看一下以下三个代码示例，其中两个使用__builtin_expect在常规 if 和三元 if 样式中，以及第三种根本不使用它。

内置.c：

int main()
{
    char c = getchar();
    const char *printVal;
    if (__builtin_expect(c == 'c', 1))
    {
        printVal = "Took expected branch!\n";
    }
    else
    {
        printVal = "Boo!\n";
    }

    printf(printVal);
}

三元.c：

int main()
{
    char c = getchar();
    const char *printVal = __builtin_expect(c == 'c', 1) 
        ? "Took expected branch!\n"
        : "Boo!\n";

    printf(printVal);
}

nobuiltin.c:

int main()
{
    char c = getchar();
    const char *printVal;
    if (c == 'c')
    {
        printVal = "Took expected branch!\n";
    }
    else
    {
        printVal = "Boo!\n";
    }

    printf(printVal);
}

当编译时-O3，所有三个结果都相同。然而，当-O被忽略（在 GCC 4.7.2 上），ternary.c 和builtin.c 都具有相同的程序集列表（在重要的地方）：

内置：

    .file   "builtin.c"
    .section    .rodata
.LC0:
    .string "Took expected branch!\n"
.LC1:
    .string "Boo!\n"
    .text
    .globl  main
    .type   main, @function
main:
.LFB0:
    .cfi_startproc
    pushl   %ebp
    .cfi_def_cfa_offset 8
    .cfi_offset 5, -8
    movl    %esp, %ebp
    .cfi_def_cfa_register 5
    andl    $-16, %esp
    subl    $32, %esp
    call    getchar
    movb    %al, 27(%esp)
    cmpb    $99, 27(%esp)
    sete    %al
    movzbl  %al, %eax
    testl   %eax, %eax
    je  .L2
    movl    $.LC0, 28(%esp)
    jmp .L3
.L2:
    movl    $.LC1, 28(%esp)
.L3:
    movl    28(%esp), %eax
    movl    %eax, (%esp)
    call    printf
    leave
    .cfi_restore 5
    .cfi_def_cfa 4, 4
    ret
    .cfi_endproc
.LFE0:
    .size   main, .-main
    .ident  "GCC: (Debian 4.7.2-4) 4.7.2"
    .section    .note.GNU-stack,"",@progbits

三元：

    .file   "ternary.c"
    .section    .rodata
.LC0:
    .string "Took expected branch!\n"
.LC1:
    .string "Boo!\n"
    .text
    .globl  main
    .type   main, @function
main:
.LFB0:
    .cfi_startproc
    pushl   %ebp
    .cfi_def_cfa_offset 8
    .cfi_offset 5, -8
    movl    %esp, %ebp
    .cfi_def_cfa_register 5
    andl    $-16, %esp
    subl    $32, %esp
    call    getchar
    movb    %al, 31(%esp)
    cmpb    $99, 31(%esp)
    sete    %al
    movzbl  %al, %eax
    testl   %eax, %eax
    je  .L2
    movl    $.LC0, %eax
    jmp .L3
.L2:
    movl    $.LC1, %eax
.L3:
    movl    %eax, 24(%esp)
    movl    24(%esp), %eax
    movl    %eax, (%esp)
    call    printf
    leave
    .cfi_restore 5
    .cfi_def_cfa 4, 4
    ret
    .cfi_endproc
.LFE0:
    .size   main, .-main
    .ident  "GCC: (Debian 4.7.2-4) 4.7.2"
    .section    .note.GNU-stack,"",@progbits

而 nobuiltin.c 则不会：

    .file   "nobuiltin.c"
    .section    .rodata
.LC0:
    .string "Took expected branch!\n"
.LC1:
    .string "Boo!\n"
    .text
    .globl  main
    .type   main, @function
main:
.LFB0:
    .cfi_startproc
    pushl   %ebp
    .cfi_def_cfa_offset 8
    .cfi_offset 5, -8
    movl    %esp, %ebp
    .cfi_def_cfa_register 5
    andl    $-16, %esp
    subl    $32, %esp
    call    getchar
    movb    %al, 27(%esp)
    cmpb    $99, 27(%esp)
    jne .L2
    movl    $.LC0, 28(%esp)
    jmp .L3
.L2:
    movl    $.LC1, 28(%esp)
.L3:
    movl    28(%esp), %eax
    movl    %eax, (%esp)
    call    printf
    leave
    .cfi_restore 5
    .cfi_def_cfa 4, 4
    ret
    .cfi_endproc
.LFE0:
    .size   main, .-main
    .ident  "GCC: (Debian 4.7.2-4) 4.7.2"
    .section    .note.GNU-stack,"",@progbits

相关部分：

基本上，__builtin_expect导致额外的代码（sete %al...) 在之前执行je .L2基于结果testl %eax, %eaxCPU 更有可能预测为 1（这里是天真的假设），而不是基于输入字符与'c'。而在 nobuiltin.c 的情况下，不存在这样的代码，并且je/jne直接与“c”进行比较（cmp $99）。请记住，分支预测主要是在 CPU 中完成的，这里 GCC 只是为 CPU 分支预测器“放置陷阱”，以假设将采取哪条路径（通过额外的代码和切换je and jne，虽然我没有这方面的资料，因为英特尔的官方优化手册 http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf没有提到对待第一次遇到je vs jne分支预测不同！我只能假设 GCC 团队通过反复试验得出了这个结论）。

我确信有更好的测试用例，可以更直接地看到 GCC 的分支预测（而不是观察对 CPU 的提示），尽管我不知道如何简洁地模拟这种情况。 （猜测：它可能会涉及编译期间的循环展开。）