为何编译器未对valarray类的add1函数做向量化优化？

代码示例 #

#include <stdlib.h>

struct va
{
    void add1(const va& other);
    void add2(const va& other);

    size_t* data;
    size_t  size;
};

void va::add1(const va& other) {
    for (size_t i = 0; i < size; ++i) {
        data[i] += other.data[i];
    }
}

void va::add2(const va& other){
    for (size_t i = 0, s = size; i < s; ++i) {
        data[i] += other.data[i];
    }
}

现象说明 #

add2函数可被MSVC、Clang、GCC、ICC等主流编译器向量化优化，但add1无法享受该优化。

核心差异根源：潜在别名与循环稳定性 #

两者的优化差异本质在于循环终止条件的确定性：

• 对于add1，循环终止条件依赖成员变量size，但编译器无法证明data指向的数组元素中不包含size本身（即data可能指向this->size的内存地址）。这意味着每次循环迭代时，data[i] += other.data[i]的操作都有可能修改size的值，导致循环终止条件在迭代过程中发生变化。这种不确定性打破了向量化的前提——向量化要求循环次数固定、迭代间无副作用依赖，因此编译器无法安全对add1做向量化。
• 对于add2，代码提前将size的值存入局部变量s，后续迭代仅读取这个局部变量。编译器可以确定：局部变量s的内存位置与data指向的数组区域相互独立（极端内存映射操作属于超出标准语义的场景，编译器默认不考虑）。因此循环终止条件固定，即便data与other.data指向的内存存在重叠，向量化后的代码依然符合标准语义，编译器可以安全执行优化。

为何编译器不对add1做额外检查优化？ #

编译器不会为add1增加额外检查来实现向量化，主要有两点原因：

• 检查成本过高：要证明data指向的数组不包含size，编译器需要追踪data的来源、指向范围等所有关联信息，这在复杂代码场景下几乎无法实现，尤其是当data是外部传入的指针时。
• 遵循标准语义：C++标准允许指针指向任意内存区域（包括对象自身的成员），编译器不能假设这种极端别名场景不存在，必须做保守处理。只有当代码通过显式操作（如add2中把size存入局部变量）消除了不确定性后，编译器才能放心进行优化。

内容的提问来源于stack exchange，提问作者Alex Guteniev