最可靠方法是直接查看生成的汇编或机器码：用llvm-objdump -d或clang -s确认是否存在目标扩展指令（如vadd.vv、lr.w、c.addi等），并核实编译时已正确传入-march而非仅-mcpu，同时需通过ir（llvm.riscv.*调用）和最终二进制双重验证。
直接看生成的汇编指令最可靠，llvm-objdump -d 或 clang -S 输出里有没有对应扩展的助记符，比查任何配置都准。
检查编译命令是否启用了目标扩展
LLVM 不会凭空生成某扩展的指令，前提是编译时明确传入了 -march。常见错误是只写了 -mcpu=generic_rv64 却漏掉 -march，结果默认只用 RV64I 基础指令集。
-
-march=rv64gcv表示启用 G（通用整数+浮点）、C（压缩）、V（向量）扩展；rv64imafdc是更常见的基础组合 - 如果用 profile 名（如
rva23u64），需确认该 profile 在 LLVM 源码中已定义，且未被标记为 experimental —— 否则要加-menable-experimental-extensions -
clang --target=riscv64 -march=rv64gc -### ...会打印完整 driver 调用链，可确认-march是否被下游llc实际接收
验证汇编输出里是否真有扩展指令
光看编译选项不保险，得见指令。RISC-V 扩展指令有明显命名特征，比如：
- V 扩展：以
v开头，如vadd.vv、vsetvli、vle32.v - A 扩展：含
lr.w、sc.w、amoswap.w - C 扩展：16-bit 指令，如
c.addi、c.lw（反汇编时通常仍显示为完整助记符，但 objdump 会标出compressed） - B 扩展：如
clz、ctz、rev8（注意：部分 B 指令在旧版 LLVM 中可能 fallback 到伪指令序列）
运行 clang -target=riscv64 -march=rv64gcv -S -o - test.c | grep -E '^(v|lr\.|sc\.|c\.)' 可快速筛出关键指令。
用 llvm-objdump 看机器码和扩展语义
汇编文本可能被优化或重排，最终二进制才是真相。对生成的 ELF 执行：
llvm-objdump -d --no-show-raw-insn binary.elf | grep -E 'vsetvli|vadd\.vv|lr\.w|c\.addi'
更进一步，加 --print-imm-hex 可看到立即数是否落在扩展要求范围内（例如 V 扩展的 vsetvli 第二操作数必须是合法的 SEW/LMUL 编码）。
- 若看到
illegal instruction异常，大概率是生成了硬件不支持的 LMUL/SEW 组合（比如 VLEN=128 却用了m8） - 若
vsetvli的第二个参数是0（即vsetvli zero, a0, e32, m1），说明 LLVM 无法静态推导 VL，转而依赖运行时传参——这本身合法，但意味着你没触发自动向量化
IR 层面看是否用了对应 intrinsic
LLVM IR 是中间态，能看出编译器“想干什么”，但不等于最终生成什么。检查 IR：
clang -target=riscv64 -march=rv64gcv -S -emit-llvm -o - test.c | grep 'llvm.riscv.'
典型输出如：
-
call @llvm.riscv.vfmacc.vv.f64m1(...)→ 表明已进入 V 扩展 intrinsic lowering 流程 -
call void @llvm.riscv.amoadd.w(...)→ A 扩展原子操作 - 没匹配到任何
llvm.riscv.*，说明 builtin 调用没被识别，或-march未生效，或 intrinsic 声明缺失
注意：@llvm.riscv.* 函数存在 ≠ 指令一定生成；后端仍可能因寄存器压力、legalization 失败等 fallback 到标量代码。
真正容易被忽略的是：LLVM 对某些扩展（尤其是 V 和 B）的 legalization 是分阶段的，IR 里看着有 intrinsic，到了 SelectionDAG 阶段可能被拆成多条基础指令，或者干脆被删掉。所以必须从汇编或机器码层回溯验证，不能只信 IR 或编译选项。
