c - GCC优化错失良机

我正在编译此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 4.4和4.7中进行了尝试，并进行了各种级别的优化，例如-O2，-O3，-Os和-Ofast。它总是给出相同的奇怪结果:

slow():

        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()代码直接从subl中的内存中使用它们，而无需先将它们加载到寄存器中。因此，slow()每个调用使用一个额外的寄存器和一个额外的指令。

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

为什么会这样呢？您能否以某种方式调整我的源代码，以便GCC可以做得更好？

编辑:这是在Mac OS上使用clang 4.2的结果:

slow():

        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的原始问题是相同的。

最佳答案

原因是在为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 - GCC优化错失良机，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/18951520/