时间戳

首页 > 解决方案 > 使用 GCC 和 GFORTRAN 进行矢量化

gcc - 使用 GCC 和 GFORTRAN 进行矢量化

问题描述

我有一个简单的循环，我希望在程序集中看到 YMM 寄存器，但我只看到 XMM

program loopunroll
integer i
double precision x(8)
do i=1,8
   x(i) = dble(i) + 5.0d0
enddo
end program loopunroll

然后我编译它（gcc或gfortran无关紧要。我使用的是gcc 8.1.0）

[user@machine avx]$ gfortran -S -mavx loopunroll.f90
[user@machine avx]$ cat loopunroll.f90|grep mm
[user@machine avx]$ cat loopunroll.s|grep mm
    vcvtsi2sd       -4(%rbp), %xmm0, %xmm0
    vmovsd  .LC0(%rip), %xmm1
    vaddsd  %xmm1, %xmm0, %xmm0
    vmovsd  %xmm0, -80(%rbp,%rax,8)

但如果我这样做，英特尔并行工作室 2018 update3：

[user@machine avx]$ ifort -S -mavx loopunroll.f90
[user@machine avx]$ cat loopunroll.s|grep mm                                                 vmovdqu   .L_2il0floatpacket.0(%rip), %xmm2             #11.8
    vpaddd    .L_2il0floatpacket.2(%rip), %xmm2, %xmm3      #11.15
    vmovupd   .L_2il0floatpacket.1(%rip), %ymm4             #11.23
    vcvtdq2pd %xmm2, %ymm0                                  #11.15
    vcvtdq2pd %xmm3, %ymm5                                  #11.15
    vaddpd    %ymm0, %ymm4, %ymm1                           #11.8
    vaddpd    %ymm5, %ymm4, %ymm6                           #11.8
    vmovupd   %ymm1, loopunroll_$X.0.1(%rip)                #11.8
    vmovupd   %ymm6, 32+loopunroll_$X.0.1(%rip)             #11.8

我还尝试了 gnu 和 intel 的标志 -march=core-avx2 -mtune=core-avx2 ，我仍然在 gnu 生产的程序集中得到相同的 XMM 结果，但在 intel 生产的程序集中得到 YMM

请问各位，我应该做些什么不同的事情？

非常感谢，M

标签： gcccompiler-optimizationavxintel-fortranavx2

解决方案

您忘记使用 启用优化gfortran。使用gfortran -O3 -march=native.

为了不完全优化，请编写一个函数（子例程），该函数（子例程）产生该子例程之外的代码可以看到的结果。例如x，作为参数并存储它。编译器必须发出适用于任何调用者的 asm，包括在调用其子例程后关心数组内容的调用者。

对于 gcc，-ftree-vectorize仅在 启用-O3，而不是-O2。

gcc 的默认值是-O0，即编译速度快，代码非常慢，但调试始终如一。

gcc 永远不会在-O0. 您必须使用-O3或-O2 -ftree-vectorize。

ifort与 gcc 不同，默认值显然包括优化。如果您不使用gcc，则不应期望ifort -S和输出远程相似。gcc -S-O3

当我使用 -O3 时，它会丢弃程序集中对 XMM 和 YMM 的任何引用。

当编译器优化掉无用的工作时，这是一件好事。

编写一个函数，该函数接受一个数组输入 arg 并写入一个输出 arg，然后查看该函数的 asm。或者对两个全局数组进行操作的函数。 不是整个程序，因为编译器具有整个程序优化。

无论如何，请参阅如何从 GCC/clang 程序集输出中删除“噪音”？有关编写有用函数以查看编译器 asm 输出的提示。这是一个 C 问答，但所有建议也适用于 Fortran：编写接受 args 并返回结果或具有无法优化的副作用的函数。

http://godbolt.org/没有 Fortran，而且编译为 fortran-xfortran似乎不起作用。g++（-xc不过，可以在 Godbolt 上编译为 C 而不是 C++。）否则，我建议使用该工具来查看编译器输出。

我为你的循环制作了一个 C 版本，以查看 gcc 对其优化器的大概相似输入做了什么。（我没有安装 gfortran 8.1，我几乎不知道 Fortran。我来这里是为了 AVX 和优化标签，但 gfortran 使用与我非常熟悉的 gcc 相同的后端。）

void store_i5(double *x) {
    for(int i=0 ; i<512; i++) {
        x[i] = 5.0 + i;
    }
}

使用i<8作为循环条件，gcc和 clang 明智地优化函数以仅从静态常量-O3 -march=haswell复制 8 s，使用. 增加数组大小，gcc 会完全展开副本以达到惊人的大尺寸，最多 143秒。但是对于 144 或更多，它会产生一个实际计算的循环。某处可能有一个调整参数来控制这种启发式。顺便说一句，clang 完全展开副本甚至 256秒，使用. 但是 512 足够大，gcc 和 clang 都可以进行计算循环。doublevmovupddoubledouble-O3 -march=haswell

gcc8.1 的内部循环（带有-O3 -march=haswell）看起来像这样，使用-masm=intel. （参见Godbolt 编译器资源管理器上的 source+asm）。

    vmovdqa ymm1, YMMWORD PTR .LC0[rip]  # [0,1,2,3,4,5,6,7]
    vmovdqa ymm3, YMMWORD PTR .LC1[rip]  # set1_epi32(8)
    lea     rax, [rdi+4096]              # rax = endp
    vmovapd ymm2, YMMWORD PTR .LC2[rip]  # set1_pd(5.0)

.L2:                                   # do {
    vcvtdq2pd       ymm0, xmm1              # packed convert 4 elements to double
    vaddpd  ymm0, ymm0, ymm2                # +5.0
    add     rdi, 64
    vmovupd YMMWORD PTR [rdi-64], ymm0      # store x[i+0..3]
    vextracti128    xmm0, ymm1, 0x1
    vpaddd  ymm1, ymm1, ymm3                # [i0, i1, i2, ..., i7] += 8 packed 32-bit integer add (d=dword)
    vcvtdq2pd       ymm0, xmm0              # convert the high 4 elements
    vaddpd  ymm0, ymm0, ymm2
    vmovupd YMMWORD PTR [rdi-32], ymm0
    cmp     rax, rdi
    jne     .L2                        # }while(p < endp);

我们可以通过使用偏移量来阻止小数组的常量传播，因此要存储的值不再是编译时常量：

void store_i5_var(double *x, int offset) {
    for(int i=0 ; i<8; i++) {
        x[i] = 5.0 + (i + offset);
    }
}

gcc 使用与上面基本相同的循环体，有一些设置，但向量常数相同。

调整选项：

某些目标上的gcc-O3 -march=native更喜欢使用 128 位向量进行自动向量化，因此您仍然不会获得 YMM 寄存器。您可以使用它-march=native -mprefer-vector-width=256来覆盖它。（https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html）。（或者对于 gcc7 及更早版本，-mno-prefer-avx128`。）

gcc 更喜欢 256 位，-march=haswell因为执行单元完全是 256 位，并且它具有高效的 256 位加载/存储。

Bulldozer 和 Zen 在内部将 256 位指令拆分为两个 128 位，因此运行两倍的 XMM 指令实际上可以更快，特别是如果您的数据并不总是按 32 对齐。或者当标量序言/尾声开销相关时. 如果您使用的是 AMD CPU，绝对可以对两种方式进行基准测试。或者实际上对于任何 CPU 这都不是一个坏主意。

同样在这种情况下，gcc 没有意识到它应该使用整数的 XMM 向量和双精度的 YMM 向量。（Clang 和 ICC 在适当的时候更擅长混合不同的向量宽度）。相反，它每次都提取 YMM 整数向量的高 128 位。所以128 位向量化有时会获胜的一个原因是，有时 gcc 在进行 256 位向量化时会自责。 （gcc 的自动矢量化通常对于宽度不同的类型很笨拙。）

使用-march=znver1 -mno-prefer-avx128，gcc8.1 使用两个 128 位半部分存储到内存，因为它不知道目标是否是 32 字节对齐的（https://godbolt.org/g/A66Egm）。 tune=znver1套-mavx256-split-unaligned-store。你可以用 覆盖它-mno-avx256-split-unaligned-store，例如，如果你的数组通常是对齐的，但你没有给编译器足够的信息。

推荐阅读