当限制为959但不是960时，为什么优化了一个简单循环？

考虑以下简单循环：

float f(float x[]) {
  float p = 1.0;
  for (int i = 0; i < 959; i++)
    p += 1;
  return p;
}

如果使用gcc 7（快照）或clang（树干）进行编译，-march=core-avx2 -Ofast则会得到非常类似的结果。

.LCPI0_0:
        .long   1148190720              # float 960
f:                                      # @f
        vmovss  xmm0, dword ptr [rip + .LCPI0_0] # xmm0 = mem[0],zero,zero,zero
        ret

换句话说，它只是将答案设置为960而不会循环。

但是，如果将代码更改为：

float f(float x[]) {
  float p = 1.0;
  for (int i = 0; i < 960; i++)
    p += 1;
  return p;
}

产生的程序集实际上执行循环总和吗？例如clang给出：

.LCPI0_0:
        .long   1065353216              # float 1
.LCPI0_1:
        .long   1086324736              # float 6
f:                                      # @f
        vmovss  xmm0, dword ptr [rip + .LCPI0_0] # xmm0 = mem[0],zero,zero,zero
        vxorps  ymm1, ymm1, ymm1
        mov     eax, 960
        vbroadcastss    ymm2, dword ptr [rip + .LCPI0_1]
        vxorps  ymm3, ymm3, ymm3
        vxorps  ymm4, ymm4, ymm4
.LBB0_1:                                # =>This Inner Loop Header: Depth=1
        vaddps  ymm0, ymm0, ymm2
        vaddps  ymm1, ymm1, ymm2
        vaddps  ymm3, ymm3, ymm2
        vaddps  ymm4, ymm4, ymm2
        add     eax, -192
        jne     .LBB0_1
        vaddps  ymm0, ymm1, ymm0
        vaddps  ymm0, ymm3, ymm0
        vaddps  ymm0, ymm4, ymm0
        vextractf128    xmm1, ymm0, 1
        vaddps  ymm0, ymm0, ymm1
        vpermilpd       xmm1, xmm0, 1   # xmm1 = xmm0[1,0]
        vaddps  ymm0, ymm0, ymm1
        vhaddps ymm0, ymm0, ymm0
        vzeroupper
        ret

为什么会这样？为什么对于clang和gcc来说却完全一样？

如果更换为同一个循环的限制float使用double是479这是gcc和铛一样了。

更新1

事实证明，gcc 7（快照）和clang（树干）的行为非常不同。据我所知，clang会针对所有小于960的限制优化循环。另一方面，gcc对精确的值敏感，没有上限。例如，它不优化圈外时的极限是200（以及许多其他的值），但它确实当极限是202和20002（以及许多其他的值）。

TL; DR

默认情况下，当前快照GCC 7的行为会不一致，而由于PARAM_MAX_COMPLETELY_PEEL_TIMES，以前的版本具有默认限制，即16。可以从命令行覆盖它。

限制的基本原理是防止过于激进的循环展开，这可能是一把双刃剑。

GCC版本<= 6.3.0

GCC的相关优化选项是-fpeel-loops，它与标志一起间接启用-Ofast（重点是我的）：

果皮循环具有足够的信息，因此不会滚动太多（来自配置文件反馈或静态分析）。它还打开了完整的循环剥离（即以较小的恒定迭代次数完全除去循环）。

通过-O3和/或启用-fprofile-use。

可以通过添加更多详细信息-fdump-tree-cunroll：

$ head test.c.151t.cunroll 

;; Function f (f, funcdef_no=0, decl_uid=1919, cgraph_uid=0, symbol_order=0)

Not peeling: upper bound is known so can unroll completely

消息来自/gcc/tree-ssa-loop-ivcanon.c：

if (maxiter >= 0 && maxiter <= npeel)
    {
      if (dump_file)
        fprintf (dump_file, "Not peeling: upper bound is known so can "
         "unroll completely\n");
      return false;
    }

因此try_peel_loop函数返回false。

可以通过以下命令获得更详细的输出-fdump-tree-cunroll-details：

Loop 1 iterates 959 times.
Loop 1 iterates at most 959 times.
Not unrolling loop 1 (--param max-completely-peeled-times limit reached).
Not peeling: upper bound is known so can unroll completely

可以通过用max-completely-peeled-insns=nand max-completely-peel-times=n参数修饰来限制：

max-completely-peeled-insns

完全剥离的循环的最大insns数。

max-completely-peel-times

循环的最大迭代次数适合完全剥离。

要了解有关insns的更多信息，请参阅《GCC内部手册》。

例如，如果使用以下选项进行编译：

-march=core-avx2 -Ofast --param max-completely-peeled-insns=1000 --param max-completely-peel-times=1000

然后代码变成：

f:
        vmovss  xmm0, DWORD PTR .LC0[rip]
        ret
.LC0:
        .long   1148207104

铛

我不确定Clang实际做什么以及如何调整其限制，但是正如我观察到的那样，您可以通过将循环标记为unroll pragma来迫使它评估最终值，它将完全删除它：

#pragma unroll
for (int i = 0; i < 960; i++)
    p++;

结果变成：

.LCPI0_0:
        .long   1148207104              # float 961
f:                                      # @f
        vmovss  xmm0, dword ptr [rip + .LCPI0_0] # xmm0 = mem[0],zero,zero,zero
        ret

阅读Sulthan的评论后，我猜是：

1. 如果循环计数器为常数（且不是太高），则编译器将完全展开循环

2. 展开后，编译器发现可以将求和运算分组为一个。

如果循环由于某种原因未展开（此处：会使用生成太多语句1000），则无法对操作进行分组。

编译器可以看到，展开1000条语句等于一次加法，但是上述步骤1和步骤2是两个单独的优化，因此，它无法承担展开的“风险”，不知道是否可以对操作进行分组（示例：函数调用无法分组）。

注意：这是一个极端的情况：谁使用循环再次添加相同的内容？在这种情况下，不要依赖编译器可能的展开/优化；直接在一条指令中编写正确的操作。

很好的问题！

您似乎在简化代码时，编译器尝试内联的迭代次数或操作数量已达到极限。正如Grzegorz Szpetkowski所记录的那样，有一些编译器特定的方法可以通过编译指示或命令行选项来调整这些限制。

您还可以使用Godbolt的Compiler Explorer来比较不同的编译器和选项如何影响所生成的代码：gcc 6.2并且icc 17仍内联960，而clang 3.9不是（对于默认的Godbolt配置，它实际上在73处停止内联）。