根本原因是LLVM默认不启用RVV向量化，必须显式配置目标三元组、-mattr=+v、最小向量长度等参数，且IR需含可伸缩类型，LoopVectorizePass才可能生成RVV指令；否则静默降级为标量代码。
LLVM 不会自动把普通循环转成 RVV 指令，根本原因不是“不支持”，而是**它默认压根不认为你想要 RVV 向量化**——除非你明确告诉它：目标平台支持 RVV、数据访问模式适合、且你愿意承担可伸缩向量带来的语义变化。
下面几个关键点直接决定 LLVM 是否启用 RVV 向量化路径：
目标三元组和扩展属性没配对，-mattr=+v 就是摆设
即使你加了 -march=riscv64，LLVM 仍按标量 RISC-V 处理。必须显式启用向量扩展：
-
-mtriple=riscv64-unknown-elf或-mtriple=riscv64-pc-linux-gnu（不能省） -
-mattr=+v是最低要求；若用浮点需补+zfh或+zfa - 必须指定最小向量长度，否则后端跳过可伸缩类型生成：
-riscv-v-vector-bits-min=256（常见值为 128/256/512/1024） - 漏掉任意一项，
llc会静默降级为标量代码，不会报错也不会警告
getCFInstrCost 在循环里一超阈值，整个向量化就被毙掉
LLVM 的 LoopVectorizePass 在合法性和收益评估阶段，会对每个控制流指令打分。比如一个 icmp slt i32 %i, %n 返回成本 42，而阈值是 38 ——就这 4 点差，整个循环直接被判定“不值得向量化”。
- 分支预测开销、select 掩码生成、predicate 插入都会推高成本
- RVV 的可伸缩性反而让 CostModel 更难建模：vscale 是运行时变量，编译期无法精确估算寄存器压力或指令延迟
- 实测中，带
if的简单循环在-O3下大概率 fallback 到标量，除非加#pragma clang loop vectorize(enable)强制
IR 层没有可伸缩向量类型，后端根本看不到“RVV 机会”
LLVM IR 必须出现 vadd.vv。但普通 C 循环经前端生成的 IR 是标量类型（i32, float），LoopVectorizePass 默认生成的是固定宽度向量（如 ），而非可伸缩类型。
- 自动向量化器（LoopVectorizePass）目前不生成可伸缩向量类型，只生成固定宽度（如 AVX 风格）
- 要触发 RVV 指令，得靠 Region Vectorizer 或手写 intrinsic，或者用 MLIR + RVV Dialect 做显式 lowering
- 即使开了
-mattr=+v，如果 IR 里全是，后端也只会尝试映射到 LMUL=1 的定长模式，而非真正利用 vscale
内存访问模式不满足 ConsecutiveStride，vle32.v 就不会出来
RVV 高效依赖连续访存。LoopVectorizePass 会检查 stride 是否为 1（正向）或 -1（反向）。但 reverse-iter 场景下 stride = -1 会导致 CostModel 多插入 shuffle 指令，最终放弃 RVV 路径。
- 非单位步长（如
a[i*2]）、间接索引（a[idx[i]]）、或结构体数组字段偏移，都会让访问判定为 non-consecutive - 即使数据物理连续，只要 IR 中 gep 计算引入复杂 offset，也会被误判
- 解决办法不是改算法，而是用
__riscv_vlsseg2e32_v_f32m1这类 strided load intrinsic 显式表达意图
最常被忽略的一点：RVV 向量化不是“开个开关就能有”，它要求从源码结构、编译参数、IR 类型到后端配置全部对齐。任何一个环节断链，生成的就只是标量汇编——而且 LLVM 还不会告诉你哪里断了。
