-rpass-missed=loop-vectorize 是诊断循环向量化失败的首选选项，它精准定位未向量化的循环并给出简明归因，比 -rpass-analysis 和 -rpass 更干净、更有针对性。
直接加 -Rpass-missed=loop-vectorize 就能看到失败原因，不用猜、不靠反汇编，LLVM 自己会告诉你卡在哪一步。
用哪个 -Rpass 选项最管用
三个相关选项里，-Rpass-missed=loop-vectorize 是诊断失败循环的首选——它只输出“本该向量化但没成功”的循环位置和一句话归因。比 -Rpass-analysis=loop-vectorize 更干净（后者会重复打印多个底层原因），也比 -Rpass=loop-vectorize（只报成功的）更有针对性。
常见组合是：
-
-Rpass-missed=loop-vectorize：定位哪几处循环被跳过 -
-Rpass-analysis=loop-vectorize：追查具体拦路虎，比如 “loop contains a switch statement” 或 “call instruction cannot be vectorized” - 加
-mllvm -debug-only=loop-vectorize可看到更底层的决策日志（如 cost model 打分、interleave factor 推导），但输出量大，适合深度排查
诊断信息里常见的错误提示含义
看到这些输出，基本不用再看代码逻辑，直接对应到硬性限制：
-
loop contains a switch statement：LLVM 默认不向量化含switch的循环，因为分支难以用 predicated execution 安全表达 -
call instruction cannot be vectorized：调用了无法内联或无向量化实现的函数（如std::rand()、printf），必须替换成纯计算逻辑或 intrinsic -
reduction variable may not be safe to transform：累加类变量（如sum += a[i]）存在跨迭代依赖，需改用#pragma clang loop vectorize_width(4) interleave_count(2)显式引导，或手动展开+局部归约 -
memory access is not consecutive：数组访问不是连续步长（如a[i*2]），或指针别名关系未明确（加restrict或__restrict__）
为什么有时候加了 -Rpass 还看不到提示
不是编译器沉默，而是条件没触发——-Rpass 系列只对实际进入 LoopVectorizePass 的循环生效。以下情况会导致“静默失败”：
- 优化级别太低：
-O0或-O1下LoopVectorizePass根本不运行，必须用-O2或更高 - 循环体为空或被常量折叠：LLVM 在早期 pass 就删掉了循环，后续 vectorizer 压根看不到它
- 用了
#pragma clang loop disable_vectorization或__attribute__((no_vectorize))主动禁用 - 目标架构不支持向量指令：比如为
-march=i386编译时，即使循环合法，vectorizer 也会跳过（此时-Rpass不输出，但 IR 里不会有shufflevector或extractelement）
确认向量化是否真的发生，不能只信 -Rpass
-Rpass 报成功，不代表最终生成了向量指令；报失败，也不代表完全没做任何向量化尝试（比如部分内层循环可能仍被 BB vectorizer 处理）。最稳妥的验证链是：
- 先用
clang -O2 -Rpass=loop-vectorize test.c看有没有 “vectorized loop (vector width: 4)” 类提示 - 再用
clang -O2 -S -o - test.c | grep -E 'vadd|movdqa|vmovdqu'（x86）或grep -E '^vadd\.|^vsetvli'（RISC-V）扫汇编关键词 - 最后用
llc -O2 -march=xxx -debug-only=loop-vectorize test.ll 2>&1 | grep -A3 -B3 "vectorized"查看 IR 到机器码阶段的实际决策
真正容易被忽略的是：LLVM 的向量化决策高度依赖上下文——同一段循环，在 -march=native 下可能成功，在 -march=haswell 下却失败，只因某条指令的成本阈值变了几个整数。别只盯着代码结构，成本模型才是那个不声不响按暂停键的人。
