GCC优化错失良机答案

【问题标题】：GCC optimization missed opportunityGCC优化错失良机
【发布时间】：2013-09-27 21:26:00
【问题描述】：

我正在编译这段 C 代码：

int mode; // use aa if true, else bb
int aa[2];
int bb[2];

inline int auto0() { return mode ? aa[0] : bb[0]; }
inline int auto1() { return mode ? aa[1] : bb[1]; }

int slow() { return auto1() - auto0(); }
int fast() { return mode ? aa[1] - aa[0] : bb[1] - bb[0]; }

slow() 和 fast() 函数都旨在做同样的事情，尽管 fast() 使用一个分支语句而不是两个。我想检查 GCC 是否会将两个分支合并为一个。我已经在 GCC 4.4 和 4.7 上尝试过，并使用了各种级别的优化，例如 -O2、-O3、-Os 和 -Ofast。它总是给出同样奇怪的结果：

慢（）：

        movl    mode(%rip), %ecx
        testl   %ecx, %ecx
        je      .L10

        movl    aa+4(%rip), %eax
        movl    aa(%rip), %edx
        subl    %edx, %eax
        ret
.L10:
        movl    bb+4(%rip), %eax
        movl    bb(%rip), %edx
        subl    %edx, %eax
        ret

快速（）：

        movl    mode(%rip), %esi
        testl   %esi, %esi
        jne     .L18

        movl    bb+4(%rip), %eax
        subl    bb(%rip), %eax
        ret
.L18:
        movl    aa+4(%rip), %eax
        subl    aa(%rip), %eax
        ret

确实，每个函数只生成一个分支。然而，slow() 似乎以一种令人惊讶的方式劣势：它在每个分支中使用了一个额外的负载，用于aa[0] 和bb[0]。 fast() 代码直接从subls 的内存中使用它们，而无需先将它们加载到寄存器中。所以slow() 每次调用使用一个额外的寄存器和一个额外的指令。

一个简单的微基准测试表明，调用 fast() 十亿次需要 0.7 秒，而 slow() 需要 1.1 秒。我使用的是 2.9 GHz 的 Xeon E5-2690。

为什么会这样？你能以某种方式调整我的源代码，让 GCC 做得更好吗？

编辑：这是 Mac OS 上 clang 4.2 的结果：

慢（）：

        movq    _aa@GOTPCREL(%rip), %rax   ; rax = aa (both ints at once)
        movq    _bb@GOTPCREL(%rip), %rcx   ; rcx = bb
        movq    _mode@GOTPCREL(%rip), %rdx ; rdx = mode
        cmpl    $0, (%rdx)                 ; mode == 0 ?
        leaq    4(%rcx), %rdx              ; rdx = bb[1]
        cmovneq %rax, %rcx                 ; if (mode != 0) rcx = aa
        leaq    4(%rax), %rax              ; rax = aa[1]
        cmoveq  %rdx, %rax                 ; if (mode == 0) rax = bb
        movl    (%rax), %eax               ; eax = xx[1]
        subl    (%rcx), %eax               ; eax -= xx[0]

快速（）：

        movq    _mode@GOTPCREL(%rip), %rax ; rax = mode
        cmpl    $0, (%rax)                 ; mode == 0 ?
        je      LBB1_2                     ; if (mode != 0) {
        movq    _aa@GOTPCREL(%rip), %rcx   ;   rcx = aa
        jmp     LBB1_3                     ; } else {
LBB1_2:                                    ; // (mode == 0)
        movq    _bb@GOTPCREL(%rip), %rcx   ;   rcx = bb
LBB1_3:                                    ; }
        movl    4(%rcx), %eax              ; eax = xx[1]
        subl    (%rcx), %eax               ; eax -= xx[0]

有趣：clang 为slow() 生成无分支条件，但为fast() 生成一个分支！另一方面，slow() 执行三个加载（其中两个是推测性的，一个是不必要的），而fast() 执行两个。 fast() 实现更“明显”，并且与 GCC 一样，它更短，使用的寄存器更少。

Mac OS 上的 GCC 4.7 通常会遇到与 Linux 相同的问题。然而，它使用与 Mac OS 上的 Clang 相同的“加载 8 个字节然后两次提取 4 个字节”模式。这有点有趣，但不是很相关，因为在 GCC 的任一平台上，使用两个寄存器而不是一个内存和一个寄存器发出 subl 的原始问题是相同的。

【问题讨论】：

只是拆解“慢”还是你分析过？这两个版本在现代 CPU 上可能具有相同的性能。由于您使用的是 x86_64，因此您不能使用 -march= 来尝试较旧的内核（假设某个基本级别的功能是 64 位的）。
这在很大程度上归结于这样一个事实，即尽管编译器擅长优化代码，但它们很少生成最佳代码。毕竟，这是一个 NP 难题。所以很多时候，他们甚至没有尝试生成最佳代码。
但是要回答你为什么会发生这种情况的问题，GCC 似乎没有尝试做最后的指令合并。
看看clang用它做了什么会很有趣。
@John，请注意 gcc 也发出条件移动，但仅在您没有在这里写的 auto0/1 中（至少它对我来说是这样，因为 auto0/1 仍然存在于它们的非内联形式）。似乎当将这段代码内联到慢时，gcc 删除了它（或者一开始就没有写），而 clang 没有 - 也许它与内联发生的阶段有关。你能用 gcc -fearly-inlining 试试吗？

标签： c optimization gcc assembly x86

【解决方案1】：

原因是在为slow()发出的初始中间代码中，内存负载和减法在不同的基本块中：

slow ()
{
  int D.1405;
  int mode.3;
  int D.1402;
  int D.1379;

  # BLOCK 2 freq:10000
  mode.3_5 = mode;
  if (mode.3_5 != 0)
    goto <bb 3>;
  else
    goto <bb 4>;

  # BLOCK 3 freq:5000
  D.1402_6 = aa[1];
  D.1405_10 = aa[0];
  goto <bb 5>;

  # BLOCK 4 freq:5000
  D.1402_7 = bb[1];
  D.1405_11 = bb[0];

  # BLOCK 5 freq:10000
  D.1379_3 = D.1402_17 - D.1405_12;
  return D.1379_3;
}

而在fast() 中，它们位于同一个基本块中：

fast ()
{
  int D.1377;
  int D.1376;
  int D.1374;
  int D.1373;
  int mode.1;
  int D.1368;

  # BLOCK 2 freq:10000
  mode.1_2 = mode;
  if (mode.1_2 != 0)
    goto <bb 3>;
  else
    goto <bb 4>;

  # BLOCK 3 freq:3900
  D.1373_3 = aa[1];
  D.1374_4 = aa[0];
  D.1368_5 = D.1373_3 - D.1374_4;
  goto <bb 5>;

  # BLOCK 4 freq:6100
  D.1376_6 = bb[1];
  D.1377_7 = bb[0];
  D.1368_8 = D.1376_6 - D.1377_7;

  # BLOCK 5 freq:10000
  return D.1368_1;
}

GCC 依赖于指令组合传递来处理这样的情况（即显然不是在窥视孔优化传递中）并且组合在基本块的范围内工作。这就是为什么在 fast() 中将减法和负载组合在一个 insn 中，而在 slow() 中甚至不考虑将它们组合在一起。

稍后，在基本块重新排序过程中，slow() 中的减法被复制并移动到包含负载的基本块中。现在组合器有机会将负载和减法组合起来，但不幸的是，组合器通道不会再次运行（也许它不能在编译过程的后期运行，因为已经分配了硬寄存器和东西）。

【讨论】：

如果您说明您如何创建上述输出，我会支持您。它不是预处理的 C 源代码，也不是汇编源代码中的调试信息。
@FrankH.，呵呵，抱歉，这是gcc -c -da -O2 slow.c 的输出，它会在每个 RTL 优化阶段生成大量带有编译单元状态转储的文件。
这个！通过在管道中的多个点重新运行各种优化通道，可以使 GCC 生成更好的代码，但它会使构建花费一整天，并且只在此处减少一条指令，在此处减少一条指令。这是速度/质量的权衡。据我所知，这个没有参数化；大概是因为实现和添加大量代码来检查极端情况等需要真正的工作。

【解决方案2】：

我不知道为什么 GCC 无法按照您希望的方式优化代码，但我有办法重新组织您的代码以实现类似的性能。我建议您定义一个内联函数，该函数基于mode 返回aa 或bb，而不是像在slow() 或fast() 中那样组织代码，而不需要分支：

inline int * xx () { static int *xx[] = { bb, aa }; return xx[!!mode]; }
inline int kwiky(int *xx) { return xx[1] - xx[0]; }
int kwik() { return kwiky(xx()); }

当 GCC 4.7 使用 -O3 编译时：

    movl    mode, %edx
    xorl    %eax, %eax
    testl   %edx, %edx
    setne   %al
    movl    xx.1369(,%eax,4), %edx
    movl    4(%edx), %eax
    subl    (%edx), %eax
    ret

有了xx()的定义，你可以像这样重新定义auto0()和auto1()：

inline int auto0() { return xx()[0]; }
inline int auto1() { return xx()[1]; }

并且，从这里，您应该看到slow() 现在编译为与kwik() 相似或相同的代码。

【讨论】：

谢谢。快速测试表明性能优于 slow() 或 fast()。但是，我认为我不能使用这个解决方案，因为在我的真实代码中，事情稍微复杂一些（duh），而且aa 实际上是一对函数而不是普通整数。
@JohnZwinck：我更新了答案以显示xx() 函数如何让您重新定义auto0() 和auto1() 以使slow() 比fast() 更快。
我不太了解...xx() 仍然包含指向int aa[2] 的指针，但在我的真实代码中，我需要为每次访问调用aa0() 和aa1()。 int bb[2] 确实是一个数组，但我不知道如何在例如aa0() 和 bb[0] 使用您的方法。我错过了什么吗？
@JohnZwinck：哦，对不起，我还在回答你发布的问题。我无法与您的真实代码交谈，因为您的问题中没有任何内容。
在实际代码中，auto0() 类似于{ return mode ? aa0() : bb[0]; }。 auto1() 也类似。这使示例有些复杂，但 GCC 在优化中犯了同样的“错误”，在 slow() 中使用了额外的指令和额外的寄存器。

【解决方案3】：

您是否尝试过修改内部编译器参数（手册页中的 --param name=value）。这些不会随着任何优化级别而改变（有三个小例外）。

其中一些控制代码减少/重复数据删除。

对于本节中的一些优化，您可以阅读诸如«较大的值可以成倍增加编译时间»之类的内容。

【讨论】：