第2章：向量化编译器基础：自动向量化原理、GCC/LLVM向量化选项、向量化报告解读

好，咱们正式开始聊编译器向量化。说实话，很多做算法移植的朋友，一上来就撸袖子写内联汇编或者 intrinsic，把编译器晾在一边。我个人习惯是，先让编译器试试看——它要是能干好，咱们省大事了。

自动向量化，说白了就是编译器替你把标量循环里的操作，自动打包成向量指令。你写个 for(i=0; i<N; i++) a[i]=b[i]+c[i];，编译器一看，嗯，数据没依赖，循环次数够，直接给你生成 vadd.vv。但现实往往没这么美好，编译器经常“看不懂”你的代码。这一章，咱们就把它看透。

2.1 自动向量化的核心原理

编译器做自动向量化，大致分三步走：

1. legality check（合法性检查）：判断循环能不能安全地并行执行。说白了就是看数据依赖——后一次迭代会不会用到前一次迭代的结果？如果有，那就没法向量化。
2. profitability check（收益性评估）：就算合法，也得算算账。向量化后性能能提升多少？会不会因为数据不对齐、循环次数太少反而变慢？
3. transformation（代码变换）：把标量循环改写成向量版本，同时生成标量回退代码（处理循环尾部的剩余元素）。

我记得有一次，团队里一个同事写了个图像滤波算法，循环里有个 if(pixel > threshold) 的分支。编译器死活不向量化。后来我们改成用 vmerge 的思路，手动把条件赋值写成无分支的掩码操作，编译器一下就认出来了。嗯，这里要注意：分支是自动向量化的天敌。

2.2 GCC 与 LLVM 的向量化选项

两个主流编译器，选项上大同小异，但细节上各有脾气。我列个表，你一看就明白。

功能	GCC 选项	LLVM/Clang 选项	说明
启用自动向量化	-O2/-O3 默认开启	-O2/-O3 默认开启	两者都在 O2 以上默认尝试向量化
强制启用向量化	-ftree-vectorize	-fvectorize	O2 下 GCC 需显式开启，LLVM 默认开
指定向量化宽度	-mvlmax=128/256	-mriscv-vector-bits=128/256	RISC-V V 扩展支持可变长度，这里设的是“期望宽度”
启用循环展开	-funroll-loops	-funroll-loops	常与向量化配合使用
生成向量化报告	-fopt-info-vec-missed	-Rpass=loop-vectorize	看编译器为什么没向量化
禁用向量化	-fno-tree-vectorize	-fno-vectorize	调试或对比性能时用

这里有个坑，我曾经踩过：GCC 的 -mvlmax 和 LLVM 的 -mriscv-vector-bits，它们设的是“编译器认为的 VLEN 上限”，不是硬件的实际 VLEN。如果你的硬件 VLEN=256，但你设了 128，编译器会按 128 来切分循环，浪费了一半的向量能力。反过来，设大了也不会出错，只是生成的代码可能不是最优。

2.3 向量化报告解读——听懂编译器在说什么

编译器就像个不太爱说话的程序员。你得用对的方式问，它才告诉你为什么没干活。

2.3.1 GCC 报告：-fopt-info-vec

GCC 的向量化报告分几个级别：

• -fopt-info-vec：只输出成功向量化的循环
• -fopt-info-vec-missed：输出所有尝试过但失败的循环
• -fopt-info-vec-all：全部输出，信息量很大

举个例子，你编译一个简单的加法循环：

// test.c
void vec_add(float *a, float *b, float *c, int n) {
    for (int i = 0; i < n; i++) {
        a[i] = b[i] + c[i];
    }
}

用 gcc -O3 -march=rv64gcv -fopt-info-vec-missed test.c -c，你会看到类似这样的输出：

test.c:2:21: optimized: loop vectorized using 16 bytes
test.c:2:21: note: loop turned into non-rotated version
test.c:2:21: note: main loop vectorized with peeling 4 iterations

这里的信息很关键：

• “loop vectorized using 16 bytes”：编译器用了 16 字节（4 个 float）的向量宽度。如果你的硬件 VLEN=256，它只用了 128 位，说明可能没充分利用。
• “peeling 4 iterations”：为了对齐，编译器把前 4 次迭代单独处理了。

如果没向量化，你会看到：

test.c:2:21: missed: couldn't vectorize the loop
test.c:2:21: missed: not vectorized: data dependence found
test.c:2:21: missed: not vectorized: unsupported control flow

最常见的失败原因就三种：数据依赖、控制流太复杂、或者访存模式不连续。

2.3.2 LLVM 报告：-Rpass 系列

LLVM 的报告更结构化一些，用 -Rpass 系列选项：

• -Rpass=loop-vectorize：成功向量化的循环
• -Rpass-missed=loop-vectorize：失败的循环
• -Rpass-analysis=loop-vectorize：详细分析原因

用 clang 编译同样的代码：

clang -O3 -march=rv64gcv -Rpass-missed=loop-vectorize test.c -c

输出可能是：

test.c:2:21: remark: loop not vectorized: loop control flow is not understood by vectorizer
test.c:2:21: remark: loop not vectorized: value that could not be identified as reduction is used outside the loop

LLVM 的 remark 比 GCC 的 note 更具体，它会告诉你“哪个值被用到了循环外面导致无法向量化”。这对定位问题非常有帮助。

2.4 向量化知识体系总览

下面这张图，把自动向量化的核心脉络串起来了。你可以把它当作本章的“思维导图”。

2.5 实战建议：如何用好自动向量化

说了这么多理论，来点实际的。我总结了几条经验：

• 先开报告，再改代码：别凭感觉猜。让编译器告诉你它卡在哪。
• 保持循环结构简单：避免函数调用、复杂条件、不连续指针。能用 restrict 关键字就用，告诉编译器指针不重叠。
• 关注循环计数：如果循环次数小于 VLEN 的元素数，向量化可能反而更慢。这时候可以手动做循环展开，或者干脆不向量化。
• 善用 pragma：GCC 和 LLVM 都支持 #pragma GCC ivdep（忽略向量依赖）和 #pragma clang loop vectorize(enable)。但别滥用——你告诉编译器“没依赖”，如果实际上有，结果就是错的。