有符号或无符号循环计数器

Question

我对这个简单示例中使用有符号循环计数器和无符号循环计数器之间的区别感到非常惊讶：

double const* a;
__assume_aligned(a, 64);
double s = 0.0;

//for ( unsigned int i = 0; i < 1024*1024; i++ )
for ( int i = 0; i < 1024*1024; i++ )
{
    s += a[i];
}

在签名的情况下，生成了 icc 19.0.0（我显示的是循环的展开部分）：

..B1.2:
    vaddpd    zmm7, zmm7, ZMMWORD PTR [rdi+rax*8]
    vaddpd    zmm6, zmm6, ZMMWORD PTR [64+rdi+rax*8]
    vaddpd    zmm5, zmm5, ZMMWORD PTR [128+rdi+rax*8]
    vaddpd    zmm4, zmm4, ZMMWORD PTR [192+rdi+rax*8]
    vaddpd    zmm3, zmm3, ZMMWORD PTR [256+rdi+rax*8]
    vaddpd    zmm2, zmm2, ZMMWORD PTR [320+rdi+rax*8]
    vaddpd    zmm1, zmm1, ZMMWORD PTR [384+rdi+rax*8]
    vaddpd    zmm0, zmm0, ZMMWORD PTR [448+rdi+rax*8]
    add       rax, 64
    cmp       rax, 1048576
    jb        ..B1.2        # Prob 99%

在无符号的情况下，icc使用额外的寄存器来寻址内存，相应的LEAs:

..B1.2:
    lea       edx, DWORD PTR [8+rax]
    vaddpd    zmm6, zmm6, ZMMWORD PTR [rdi+rdx*8]
    lea       ecx, DWORD PTR [16+rax]
    vaddpd    zmm5, zmm5, ZMMWORD PTR [rdi+rcx*8]
    vaddpd    zmm7, zmm7, ZMMWORD PTR [rdi+rax*8]
    lea       esi, DWORD PTR [24+rax]
    vaddpd    zmm4, zmm4, ZMMWORD PTR [rdi+rsi*8]
    lea       r8d, DWORD PTR [32+rax]
    vaddpd    zmm3, zmm3, ZMMWORD PTR [rdi+r8*8]
    lea       r9d, DWORD PTR [40+rax]
    vaddpd    zmm2, zmm2, ZMMWORD PTR [rdi+r9*8]
    lea       r10d, DWORD PTR [48+rax]
    vaddpd    zmm1, zmm1, ZMMWORD PTR [rdi+r10*8]
    lea       r11d, DWORD PTR [56+rax]
    add       eax, 64
    vaddpd    zmm0, zmm0, ZMMWORD PTR [rdi+r11*8]
    cmp       eax, 1048576
    jb        ..B1.2        # Prob 99%

对我来说，令人惊讶的是它没有生成相同的代码（给定编译时循环计数）。是编译器优化问题吗？

编译选项： -O3 -march=skylake-avx512 -mtune=skylake-avx512 -qopt-zmm-usage=high

Answer 1

这是 ICC 愚蠢的遗漏优化。它不是特定于 AVX512；它仍然发生在 default/generic arch 设置中。

lea ecx, DWORD PTR [16+rax] 正在计算 i+16 作为展开的一部分，截断为 32 位（32 位操作数大小），零扩展为 64 位（隐含在 x86-写入 32 位寄存器时为 64）。这明确地实现了类型宽度处无符号环绕的语义。

gcc 和 clang 可以毫无问题地证明 unsigned i 不会换行，因此他们可以优化从 32 位无符号到 64 位指针宽度的零扩展以用于寻址模式, 因为循环上限已知¹.

回想一下，无符号环绕在 C 和 C++ 中定义明确，但有符号溢出是未定义的行为。这意味着可以将带符号的变量提升为指针宽度，并且编译器不必在每次将它们用作数组索引时都将符号扩展重做为指针宽度。（a[i] 等同于 *(a+i)，将整数添加到指针的规则意味着对于寄存器的高位可能不匹配的窄值，符号扩展是必要的。）

有符号溢出 UB 是 ICC 能够正确优化有符号计数器的原因，即使它无法使用范围信息。另见 http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html（关于未定义的行为）。请注意，它使用 add rax, 64 和 cmp 以及 64 位操作数大小（RAX 而不是 EAX）

我将您的代码制作成 MCVE 以与其他编译器一起测试。 __assume_aligned 仅适用于 ICC，因此我使用了 GNU C __builtin_assume_aligned。

#define COUNTER_TYPE unsigned

double sum(const double *a) {
    a = __builtin_assume_aligned(a, 64);
    double s = 0.0;

    for ( COUNTER_TYPE i = 0; i < 1024*1024; i++ )
        s += a[i];
    return s;
}

clang 像这样编译你的函数 (Godbolt compiler explorer):

# clang 7.0 -O3
sum:                                    # @sum
    xorpd   xmm0, xmm0
    xor     eax, eax
    xorpd   xmm1, xmm1
.LBB0_1:                                # =>This Inner Loop Header: Depth=1
    addpd   xmm0, xmmword ptr [rdi + 8*rax]
    addpd   xmm1, xmmword ptr [rdi + 8*rax + 16]
    addpd   xmm0, xmmword ptr [rdi + 8*rax + 32]
    addpd   xmm1, xmmword ptr [rdi + 8*rax + 48]
    addpd   xmm0, xmmword ptr [rdi + 8*rax + 64]
    addpd   xmm1, xmmword ptr [rdi + 8*rax + 80]
    addpd   xmm0, xmmword ptr [rdi + 8*rax + 96]
    addpd   xmm1, xmmword ptr [rdi + 8*rax + 112]
    add     rax, 16                                  # 64-bit loop counter
    cmp     rax, 1048576
    jne     .LBB0_1

    addpd   xmm1, xmm0
    movapd  xmm0, xmm1         # horizontal sum
    movhlps xmm0, xmm1              # xmm0 = xmm1[1],xmm0[1]
    addpd   xmm0, xmm1
    ret

我没有启用 AVX，这不会改变循环结构。请注意，clang 仅使用 2 个向量累加器，因此如果数据在 L1d 缓存中很热，它会在 FP 上增加瓶颈，在最近的 CPU 上增加延迟。 Skylake 一次最多可以保持 8 addpd 处于飞行状态（每个时钟吞吐量 2 个，延迟为 4 个周期）。因此，对于（某些）数据在 L2 或尤其是 L1d 缓存中很热的情况，ICC 做得更好。

奇怪的是 clang 没有使用指针增量，如果它要 add/cmp 的话。它只需要在循环之前执行一些额外的指令，并且会简化寻址模式，即使在 Sandybridge 上也允许负载的微融合。（但它不是 AVX，所以 Haswell 和后来的人可以保持负载微融合。Micro fusion and addressing modes）。 GCC 这样做，但根本不展开，这是 GCC 的默认设置，没有配置文件引导的优化。

无论如何，ICC 的 AVX512 代码将取消层压到单独的负载中，并在 issue/rename 阶段添加 uops（或者在添加到 IDQ 之前，我不确定）。所以它不使用指针增量来节省前端带宽，消耗更少的 ROB space 以获得更大的乱序 window，并且对超线程更友好，这是非常愚蠢的。

脚注 1：

（即使不是，没有像 volatile 或 atomic 访问这样的副作用的无限循环是未定义的行为，所以即使 i <= n 有运行时-变量 n，编译器将被允许假设循环不是无限的，因此 i 没有换行。Is while(1); undefined behavior in C?)

在实践中，gcc 和 clang 没有利用这一点，并创建了一个实际上可能是无限的循环，并且由于可能的怪异而没有自动矢量化。所以避免 i <= n 和运行时变量 n，尤其是对于无符号比较。请改用 i < n。

如果展开，i += 2 可以产生类似的效果。

所以在源代码中执行结束指针和指针递增通常是好的，因为这通常是 asm 的最佳选择。

有符号或无符号循环计数器

Signed or unsigned loop counter

optimization

assembly

icc

compiler-optimization

unsigned-integer