gcc的奇怪/错误的程序集输出？

Question

我有以下代码（最小示例）：

#include <iostream>
#include <immintrin.h>

using namespace std;

int main(){
    __m128i a = _mm_set_epi32(rand(),rand(),rand(),rand());
    __m128i b = _mm_set_epi32(rand(),rand(),rand(),rand());
    __m128i c = _mm_add_epi32(a,b);
    int d[4];
    _mm_storeu_si128((__m128i*)d,c);
    cout<<d[0]<<endl;
    cout<<d[1]<<endl;
    cout<<d[2]<<endl;
    cout<<d[3]<<endl;
    return 0;
}

当使用g++ -O3 -march=native 编译时，它会产生一些奇怪/错误/低效的程序集 (https://godbolt.org/z/TQgbim)。它存储c 一次，然后执行对齐加载和提取以执行元素访问（每次）。我可以看到为什么它需要将它存储到内存中，并且我可以看到对齐的加载和提取可能是如何高效的，但我不明白为什么它需要在提取后继续将相同的数据加载回 xmm 寄存器。此外，当d 被更改以便分配在堆上（https://godbolt.org/z/Pk7qP2）时，它甚至不再进行对齐加载，它只是将d 视为普通数组并以这种方式访问​​元素。有人可以解释它为什么这样做以及它可能带来什么好处吗？谢谢。

Answer 1

是的，这是一个有趣的优化失误。

看起来它决定优化向量存储/标量重新加载到向量提取中，这通常很好。

但它没有考虑调用约定，它没有保留调用的向量寄存器。这段代码在 Windows x64 上会很好，例如它可以使用 xmm6。

如果您调用内联的函数，或者如果您将所有 4 个元素作为 args 传递给同一个函数，则此代码也可以。 （例如printf）。

GCC 有多个通道，并且在程序逻辑的 GIMPLE 表示上运行的与体系结构无关的中间通道有时无法利用直到寄存器分配时间才知道的全部细节。一些优化对于 gcc 来说很难，因为它没有连接到能够看到它们。

---

顺便说一句，如果您关心这种效率水平，请使用'\n' 而不是endl。您不需要在那里显式刷新cout。