-mcpu决定指令集可用性与默认微架构特性，-mtune仅影响代码生成策略（如寄存器分配、调度顺序），不改变实际生成的指令；因-mcpu被LLVM RISC-V后端视为目标硬件能力声明，隐式启用对应扩展和特权级，而-mtune仅在指令调度前调整优化偏好，无法绕过-mcpu的ISA限制。
直接说结论：-mcpu 决定指令集可用性与默认微架构特性，-mtune 只影响代码生成策略（如寄存器分配、调度顺序），不改变生成的指令本身。
为什么 -mcpu 会决定你能用哪些指令
LLVM 的 RISC-V 后端把 -mcpu 当作“目标硬件能力声明”：它不仅指定优化目标，还隐式启用对应微架构支持的扩展和特权级别。比如：
-
-mcpu=generic-rv64→ 默认只启用基础rv64i+m+a+f+d，不生成v（向量）或zba指令 -
-mcpu=rocket-rv64→ 启用rv64imafdc，且允许生成amoorw这类原子指令（因为 Rocket 核支持 A 扩展） -
-mcpu=thead-c906→ 启用rv64imafdc_zicsr_zifencei_zba_zbb_zbc_zbs，并允许使用clz、ctz等位操作指令
如果你写了 __builtin_riscv_vsetvl 却用 -mcpu=generic-rv64 编译，Clang 会直接报错：error: use of unknown builtin '__builtin_riscv_vsetvl' —— 不是因为函数名写错，而是 -mcpu 没打开 v 扩展，整个向量 builtin 集合都被禁用了。
-mtune 实际只改调度模型和寄存器偏好
-mtune 不影响 IR 生成阶段是否允许用某条指令，它只在后端 CodeGen 的指令选择（Instruction Selection）之后、指令调度（Instruction Scheduling）之前起作用。典型影响包括：
- 对同一段 IR，
-mtune=sifive-u74可能优先选addi+ld组合，而-mtune=rocket-rv64更倾向用lw带偏移的单指令 - 寄存器分配时，
-mtune会影响 LLVM 对“哪个寄存器更可能被频繁重用”的启发式判断 - 循环展开阈值、分支预测 hint 插入策略也会随
-mtune微调
但注意：如果源码里明确写了 asm volatile ("vsetvl x0, a0, e32"），即使 -mtune 换成不支持向量的型号，这条内联汇编照样过；而 -mcpu 换成不带 v 的，则连 #include <riscv_vector.h></riscv_vector.h> 都会失败。
常见组合误区与实操建议
实际构建 RISC-V 固件或裸机程序时，最容易踩的坑是混用不匹配的 -mcpu 和 -mtune：
- 别用
-mcpu=generic-rv32 -mtune=thead-c906：前者禁止所有 vendor 扩展，后者再怎么调优也发不出cmov - 交叉编译 Linux 用户态程序时，
-mcpu=generic-rv64+-mtune=native是安全的——只要你的 host 是 RISC-V，native就只是告诉后端“按当前 CPU 调度”，不会引入非法指令 - 做芯片 bring-up 阶段，建议先固定
-mcpu为芯片手册明确列出的型号（如cv32e40p），再单独调-mtune测性能差异；不要反过来
真正要命的不是参数本身，而是误以为 -mtune 能绕过 -mcpu 的指令集限制——它不能。LLVM 的 RISC-V 后端在 Machine Function Analysis 阶段就根据 -mcpu 锁死了 ISA 选项，-mtune 只是在这个框里做排列组合。
