为何GCC/Clang在可行时不将128位SIMD内联函数向量化为256位？

现象原因 #

• 手动SIMD的语义约束：你通过__m128i和_mm_add_epi32给编译器明确了指令——就要用128位的SIMD操作。这些类型和内在函数是架构特定的语义约定，编译器会严格遵守，不会随意将两个128位操作合并为256位，避免违背代码的预期逻辑。
• 自动向量化的无约束优势：第一个函数的原生C代码没有任何SIMD相关的硬限制，编译器可以完全根据目标架构（这里是AVX2）选择最优的向量宽度，自动把循环打包成256位操作，最大化利用硬件能力。
• 数组类型的语义边界：__m128i*指向的是由独立128位SIMD单元组成的数组，编译器会认为每个数组元素都是不可拆分合并的128位块，就像不能把两个int强行合并成long处理一样，类型语义不允许这种操作。

解决办法 #

1. 条件编译适配不同架构的SIMD宽度 #

直接针对AVX2使用256位的类型和内在函数，同时保留对旧架构的兼容：

#ifdef __AVX2__
typedef __m256i vec_int_t;
#define VEC_ADD_EPI32 _mm256_add_epi32
#else
typedef __m128i vec_int_t;
#define VEC_ADD_EPI32 _mm_add_epi32
#endif

void test_vec(vec_int_t* a, vec_int_t* b, size_t n) {
    for (size_t i = 0; i < n; ++i) {
        a[i] = VEC_ADD_EPI32(a[i], b[i]);
    }
}

编译时如果开启AVX2，就会自动生成256位指令。

2. 放弃手动SIMD，依赖编译器自动优化 #

如果代码逻辑允许，优先编写原生C代码（比如第一个test32函数），让编译器根据目标架构自动选择最优的向量宽度。这种方式代码更简洁，也能充分利用编译器的优化能力，无需手动适配SIMD宽度。

3. 编译器优化提示（效果有限） #

部分编译器支持优化属性，比如GCC的__attribute__((optimize("tree-vectorize")))，但这种方法效果不确定——因为手动SIMD的语义约束优先级更高，编译器不会轻易违背你的指令去合并操作。

内容的提问来源于stack exchange，提问作者Elliot Gorokhovsky