一段循环里同时出现向量指令和标量指令，并不意味着编译器“只优化了一半”。标量部分可能处理尾部，也可能在指针重叠时保留原始语义。删掉它之前，需要知道它守住了哪个条件。
LLVM 的向量化文档说明了运行时别名检查以及标量回退。restrict或其他不别名承诺能帮助优化，但承诺一旦被调用方违反，结果不再受原来的语义保护。Rust 的切片接口可以表达部分独占关系；经过原始指针或 FFI 后，责任仍在接口作者。
运行时守卫选择向量路径，标量路径保留尾部或别名语义。
下面的最小 C++ 程序不使用编译器专有 pragma。长度取 19，故意不对齐常见向量宽度；结果由独立公式检查。保存为vec.cpp，可用clang++ -std=c++17 -O3 -Rpass=loop-vectorize vec.cpp -o vec && ./vec检查当前编译器诊断。
#include <cassert> #include <cstddef> #include <iostream> #include <vector> void axpy(float* y,const float* x,std::size_t n,float a){ for(std::size_t i=0;i<n;++i) y[i]=a*x[i]+y[i]; } int main(){ std::vector<float> x(19),y(19,1.0f); for(std::size_t i=0;i<x.size();++i) x[i]=float(i); axpy(y.data(),x.data(),x.size(),2.0f); for(std::size_t i=0;i<x.size();++i) assert(y[i]==2.0f*float(i)+1.0f); std::cout<<"AXPY tail case passed\n"; }三份材料要一起看
源代码告诉我们计算意图，优化诊断告诉我们编译器为何做或不做某个变换，汇编告诉我们最终发出了什么。诊断中显示向量化，不代表输入规模足以摊薄检查开销；汇编中出现 FMA，也不能直接推导端到端加速。
编译目标决定可用指令。Apple Silicon 上的成功编译只能说明该目标路径有效，不能替 x86 的 AVX2 或 AVX-512 背书。浮点收缩和fast-math也会改变语义边界，不能在误差合同未知时只为了看到更漂亮的汇编而打开。
2026 年 10 月 15 日 Rust 1.99.1修复的wcslen链接问题与 LLVM 的循环惯用法识别有关。这个小发布很能说明问题：优化不只涉及算得多快，还会引入运行时依赖。看编译器生成了什么，比凭循环外观猜它应该生成什么可靠。
给诊断消息配一个可以复查的结论
编译命令中的优化级别和目标架构应完整保留。-O3是请求编译器采用一组优化策略，不是“已经使用某条向量指令”的证据。诊断显示循环被向量化后，可以继续查看对应循环的汇编，并检查运行时守卫与尾部代码是否还在。若编译器把整段计算常量折叠了，也不能拿剩下的几条指令评估原循环吞吐。
别名情景可以具体想象：若 y 指向 x 后一个元素，当前写入可能影响下一次读取。编译器若不能证明这件事不会发生，就需要保守处理或运行时检查。调用者有时确实能保证不重叠，但这个保证应由接口表达，并由测试覆盖，而不是藏在优化作者的直觉里。
长度十九的测试只覆盖一种尾部，不覆盖所有余数。要验证手写向量版本，应针对实际宽度检查多个余数，再检查起始指针未对齐的情景。测试内存前后的保护区也有帮助：数值结果正确，并不排除越界写刚好落在仍可访问的地址上。
这与性能测试又有区别。微小数组更容易受调用和守卫成本影响，大数组则可能受缓存和带宽限制。比较时应该固定相同语义、相同数据和相同计时范围。否则一个版本把初始化算进去，另一个版本只算热循环，得到的差距无法解释优化本身。
本文没有提供速度排行榜，也没有验证所有 ISA。可复用的工作方式是保存编译命令与诊断，再用尾部、别名和异常输入约束优化的合法范围。
