用于 simd 的 pragma omp 不会在 GCC 中生成向量指令

Question

简短：pragma omp for simd OpenMP 指令是否生成使用 SIMD 寄存器的代码？

更长： 正如OpenMP documentation 中所述，“worksharing-loop SIMD 构造指定一个或多个相关循环的迭代将分布在已经存在的线程中 [..] 使用 SIMD 指令”。从这个声明中，我希望以下代码 (simd.c) 在编译运行 gcc simd.c -o simd -fopenmp 时使用 XMM、YMM 或 ZMM 寄存器，但事实并非如此。

#include <stdio.h>
#define N 100

int main() {
    int x[N];
    int y[N];
    int z[N];
    int i;
    int sum;

    for(i=0; i < N; i++) {
        x[i] = i;
        y[i] = i;
    }

    #pragma omp parallel
    {
        #pragma omp for simd
        for(i=0; i < N; i++) {
            z[i] = x[i] + y[i];
        }
        #pragma omp for simd reduction(+:sum)
        for(i=0; i < N; i++) {
            sum += x[i];
        }
    }
    printf("%d %d\n",z[N/2], sum);

    return 0;
}

在检查运行gcc simd.c -S -fopenmp 生成的汇编程序时，没有使用SIMD 寄存器。

我可以使用 -O3 选项在没有 OpenMP 的情况下使用 SIMD 寄存器，因为根据 GCC documentation 它包括-ftree-vectorize 标志。

• XMM 寄存器：gcc simd.c -o simd -O3
• YMM 寄存器：gcc simd.c -o simd -O3 -march=skylake-avx512
• ZMM 寄存器：gcc simd.c -o simd -O3 -march=skylake-avx512 -mprefer-vector-width=512

但是，将标志 -march=skylake-avx512 -mprefer-vector-width=512 与 -fopenmp 结合使用不会生成 SIMD 指令。

因此，我可以使用 -O3 轻松地对我的代码进行矢量化，而无需使用 pragma omp for simd，但反之则不行。

此时，我的目的不是生成 SIMD 指令，而是了解 OpenMP SIMD 指令如何在 GCC 中工作，以及如何仅使用 OpenMP（没有-O3）生成 SIMD 指令。

Answer 1

至少启用 -O2 以使 -fopenmp 正常工作并提高性能

gcc simd.c -S -fopenmp

GCC 的默认值为 -O0，针对一致的调试进行了反优化。它永远不会使用-O0 进行自动矢量化，因为当C 源代码中的每个i 值都必须存在于内存中时，它是没有意义的，依此类推。 Why does clang produce inefficient asm with -O0 (for this simple floating point sum)?

当您必须能够一次单步执行一个源代码行，甚至在运行时使用调试器修改 i 或内存内容，并让程序像您期望的 C 一样继续运行时，这也是不可能的抽象机器会。

没有任何优化的构建对于性能来说是完全垃圾；考虑到是否足够关心性能以使用 OpenMP 是很疯狂的。（当然，实际调试除外。）通常，从反优化到优化标量的加速比向量化该标量所能获得的要多代码，但两者都可能是很大的因素，因此您肯定需要自动矢量化之外的优化。

---

我可以使用-O3 选项在没有 OpenMP 的情况下使用 SIMD 寄存器，因为根据 GCC 文档，它包含 -ftree-vectorize 标志。

好吧，那就这样吧。 -O3 -march=native -flto 通常是在编译主机上运行的代码的最佳选择。此外，-fno-trapping-math -fno-math-errno 应该对一切都是安全的，并启用一些更好的 FP 函数内联，即使您不想要 -ffast-math。还优选地@ 987654336 ///////////////////////////////////////// @剖面引导优化（PGO），展开热环，并选择Branchy VS. Brantly等。

#pragma omp parallel 在-O3 -fopenmp 上仍然有效 - 默认情况下，GCC 不启用自动并行化。

另外，#pragma omp simd 有时会使用不同的矢量化样式。在您的情况下，似乎让 GCC 忘记了它知道数组是 16 字节对齐的，并使用 movdqu 加载（当 AVX 不适用于 paddd xmm0, [rax] 的未对齐内存源操作数时）。比较 https://godbolt.org/z/8q8Dqm - main 调用的 main._omp_fn.0: 辅助函数不假定对齐。 （尽管如果 GCC 不费心做向量大小的块，在除以线程数之后可能无法将数组拆分为范围？）

---

使用-O2 -fopenmp 得到你所期望的

OpenMP 将让 gcc 更容易或更有效地矢量化循环，其中您没有在指向函数的指针参数上使用 restrict 以让它知道数组不重叠，或者让浮点让它假装 FP 数学即使您没有使用 -ffast-math 也是关联的。

或者如果您启用了一些优化但没有完全优化（例如，-O2 不包括 -ftree-vectorize），那么#pragma omp 将按照您预期的方式工作。

请注意，x[i] = y[i] = i; init 循环不会在 -O2 处自动矢量化，但 #pragma 循环会。没有-fopenmp，纯标量。 Godbolt compiler explorer

---

对于这个小的N，串行-O3 代码将运行得更快，因为线程启动开销远不值得。但是对于大 N，如果单核不能使内存带宽饱和（例如在 Xeon 上，但大多数双核/四核台式机 CPU 几乎可以用一个核使内存带宽饱和），并行化可能会有所帮助。或者，如果您的阵列在不同内核的缓存中很热。

不幸的是（？）即使 GCC -O3 也无法通过您的整个代码进行持续传播，而只是打印结果。或者将z[i] = x[i]+y[i] 循环与sum(x[]) 循环融合。