为何GCC无法优化同一缓冲区双位置递增的循环？

问题代码与现象 #

原始代码如下：

unsigned int getid();
void foo(unsigned int *counter, unsigned int n) {
        unsigned int A = getid();
        unsigned int B = getid();
        for (unsigned int i = 0; i < n; i++) {
            ++counter[A];
            ++counter[B];
        }
}

观察到的优化差异：

• 即使开启-O3级别的优化，编译器依然会保留循环结构，每次执行add 1指令分别递增counter[A]和counter[B]；
• 但如果删除++counter[B]这一行，编译器会直接将循环优化为counter[A] += n，彻底消除循环。

核心疑问 #

明明就算A和B是同一个索引，直接执行counter[A] += n、counter[B] += n的结果（最终counter[A]增加2n）和循环里每次加两次1的结果完全一致，为什么编译器不肯做这个优化？

原因解析 #

核心问题在于编译器无法证明counter指针的指向范围不会覆盖函数内的其他变量，这涉及到C语言的指针别名规则和编译器的保守语义保证：

1. 无法排除别名风险
   编译器不知道getid()会返回什么值，也不知道counter指向的缓冲区边界在哪里。比如存在这样的极端情况：getid()返回的索引刚好让counter[A]直接指向变量n的内存地址。这时循环里的++counter[A]会不断修改n的值，导致循环的终止条件i < n不断变化——可能提前结束，甚至变成无限循环。如果编译器贸然把循环改成counter[A] += n，用初始的n值去做批量加法，结果会和原代码完全不符。

2. 严格的语义保证要求
   C标准要求编译器必须严格保证优化后的代码和原代码的语义完全一致，哪怕是极端的边界情况。只要存在任何一种可能让优化后的代码行为偏离原代码的场景，编译器就不能进行这个优化——哪怕你作为开发者知道counter是独立的缓冲区，不会和n、A、B重叠，但编译器没法从代码里得到这个保证。

解决办法 #

如果想让编译器放心优化，可以用restrict关键字修饰counter指针，明确告诉编译器：这个指针指向的内存区域不会和其他任何指针（包括指向n、A、B的隐式指针）产生别名。修改后的函数声明如下：

void foo(unsigned int *restrict counter, unsigned int n)

加上restrict后，编译器就能安全地把循环优化为批量加法操作了。

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