-march和-mtune需严格匹配硬件：-march必须精确反映实际ISA支持（如rv64imac缺一不可），-mtune应选最贴近目标微架构的选项（如sifive-7-series），不匹配会引发错误或性能下降；-O2 -flto=thin比单纯调优更关键，因LTO可跨函数优化寄存器与内存访问，显著提升RISC-V性能。
直接看 -march 和 -mtune 的组合是否匹配你的硬件，而不是盲目套用 profile 名称。 LLVM 的 RISC-V 后端不会自动识别你手头那颗定制芯片的微架构特性，它只认你明确告诉它的指令集和调优目标。
怎么选 -march：先确认硬件支持哪些扩展
LLVM 不会帮你做硬件探测，-march 必须严格对应你实际运行环境的 ISA 支持能力。常见错误是把开发板文档写的“支持 RV64GC”直接当 -march=rv64gc 用，却忽略了芯片其实没实现 A（原子）扩展——结果链接时报 undefined reference to __atomic_fetch_add_4。
-
-march=rv64imac表示必须有整数（I）、乘除（M）、原子（A）、压缩（C）四部分；少一个，生成的指令就可能非法 - 带
_z的扩展（如zicsr、zifencei）需显式写出，rv64gc不隐含它们 - 使用
rvi20u64这类 profile 是快捷方式，但仅限于标准配置；自研核或 FPGA 实现常需手工拼写，比如rv64imafdc_zicsr_zifencei - 启用实验性扩展（如
zicond）必须加-menable-experimental-extensions，否则 clang 直接报错
怎么配 -mtune：不是选“最强”，而是选“最像”
-mtune 告诉 LLVM 你期望代码在哪个微架构上跑得最好，但它不改变指令集兼容性。LLVM 当前支持的 -mtune 值有限，且多数只影响流水线调度模型，不改寄存器分配策略。
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 可用值包括
generic、rocket、sifive-7-series、thead-c906等；没有对应型号时，-mtune=generic反而是更安全的选择 -
-mtune=sifive-7-series会让 LLVM 避免生成跨周期依赖强的指令序列，但如果你跑在 C910 上，它反而可能错过更优的发射窗口 - 不要混用
-mtune和非匹配-march，例如-march=rv32i -mtune=thead-c906会触发警告，因为后者依赖M扩展 - 调试时可加
-mllvm -print-machineinstrs观察调度后指令顺序，验证-mtune是否生效
为什么 -O2 -flto=thin 比单靠 -mtune 更关键
对 RISC-V 来说，真正影响性能上限的往往不是单条指令调度，而是跨函数的寄存器压力与内存访问模式。LLVM 的 -mtune 仅作用于机器指令级，而 LTO 能让优化器看到整个模块的变量生命周期。
-
-flto=thin在编译期保留 bitcode，链接时重跑 IR 优化，这对 RISC-V 的 load-store 架构特别有效——能合并冗余的lw/sw对 - 搭配
-march=rv64gczicsr使用时，LTO 可能把原本分散在多个函数里的 CSR 访问（如csrrw）内联并复用寄存器，减少上下文切换开销 - 若你启用了 RVV 向量扩展，
-flto还能让向量化决策跨函数边界传播，避免因函数边界导致的向量长度截断 - 注意：ThinLTO 需要链接器支持（
lld推荐），ld.bfd可能无法正确处理 RISC-V 的 LTO 符号重定位
真正容易被忽略的是：LLVM 的 RISC-V 后端目前仍把 vfmacc.vv 当作默认向量乘加指令，即使硬件原生支持更省功耗的 vfmacc.vf（标量广播）。这类细节不会出现在 -march/-mtune 文档里，得靠 llc -debug-only=isel 看 SelectionDAG 日志才能发现。
