将应用从 x86/Arm 迁移到 RISC-V 后，性能往往无法直接对标——同一份 C 代码在不同架构上的表现差异，大部分来自编译器目标配置、向量化策略和内存访问模式这三个环节。本文从这三方面梳理 RISC-V 上的性能优化路径，所有内容基于当前主线工具链和内核的实际支持状态。
一、编译器参数：-march、-mcpu 与 -mtune 的作用层次
RISC-V 的目标配置有三个独立层次，理解其分工是调优的第一步：
●
-march=rv64gcv：决定生成的指令集。只影响"能用哪些指令"，不影响调度。指定 v 才会生成 RVV 向量指令。
●
-mcpu=xt-c920：同时设定架构与微架构调度模型（指令成本、流水线参数）。当前上游 GCC 已收录玄铁 xt-c908/xt-c910/xt-c920 等 target（xt-c950 尚在回合中），详见 GCC RISC-V Options 文档。
●
-mtune=：只设定调度模型，不改指令集。适合"为 A 核调度、在 B 核运行"的场景。GCC 文档明确 -mcpu 不覆盖 -march 与 -mtune，三者同时指定时 -march 优先决定指令集。
-mtune 的收益与编译器版本、目标核的组合强相关，不存在普遍适用的结论。一个可参考的数据点：在 SiFive U74 这类顺序双发射核上，GCC 12 的 -mtune=sifive-u74 在部分基准中几乎无差异，而同一份 C 代码经 LLVM 加 -mtune 编译后性能提升近一倍——该结果反映的是当时 LLVM RISC-V 后端调度优化尚不充分，不代表任意工具链组合下 -mtune 都有此收益。随着各家后端成熟，这类差异正在收敛，但"改参数前先测量"仍是基本原则。
代码模型：GCC 的 RISC-V 默认代码模型通常为 medlow，要求程序及静态符号位于单个 2 GiB 地址范围内；medany 则允许程序及静态符号位于任意单个 2 GiB 地址范围内，Linux 内核默认采用 medany。实际用户态默认值取决于具体 GCC 构建配置。
LTO 与 PGO：-flto 在 RISC-V 上与 x86 行为一致，可跨翻译单元内联；PGO（-fprofile-generate/-fprofile-use）对分支密集代码（解析器、状态机）收益明显。两者与 -mcpu 配合使用效果叠加。
运行时扩展检测：单二进制跨平台运行时，Linux 6.4+ 提供 riscv_hwprobe 系统调用，可查询扩展支持情况和非对齐访问性能：标量非对齐访问可查询 scalar misaligned 性能信息，RVV 场景还可查询 vector misaligned 性能信息。相比传统 HWCAP 查询，riscv_hwprobe 支持多字母扩展名（Zba/Zbb/Zbs），且 key 语义有版本化定义，提供更细粒度的硬件能力信息。GCC/Clang 对 RISC-V 函数多版本化的支持与具体工具链版本和实现方式有关。对于不支持目标形式多版本化的工具链，可以通过拆分编译单元和运行时分发实现不同 ISA/微架构版本，参考 RISE 项目 RISC-V Optimization Guide。
二、RVV 向量化：VLEN 无关模型下的正确姿势
RVV 与 x86 AVX 的根本差异是VLEN 不是编译期常量。向量寄存器组总长 VLEN×LMUL 由硬件决定，软件通过 vsetvli 按剩余数据量动态设置单次处理元素数（VL）。这套模型的核心价值是同一份二进制可在 VLEN=128/256/512 的核上运行，代价是编译器和开发者都必须写长度无关的代码。
自动向量化现状
●
LLVM：循环向量化器和 SLP 向量化器均默认开启 RVV 代码生成。-march=rv64gcv 即可触发，无需额外参数。GCC 15 起 -O2 下循环向量化默认更激进。近两年的主要改进：利用 VL 寄存器做 tail folding 消除标量尾部循环——Igalia 在 LLVM RISC-V 后端的一项评测中报告 SPEC CPU 2017 geomean 提升 8.7%，该数字基于其特定评测配置，实际收益随平台与工作负载变化；SLP 支持非 2 的幂向量化（RGB 像素等结构体一次装载）。
●
验证手段：不要假设循环被向量化了。GCC 用 -fopt-info-vec-missed 查看失败原因，LLVM 用 -Rpass-missed=loop-vectorize。两条命令应进入 CI，防止重构后静默去向量化。
LMUL 与寄存器压力
-mllvm -riscv-v-register-bit-width-lmul（LLVM）或 -mrvv-max-lmul（GCC）控制循环体内的 LMUL 上限。LMUL 越大，单条指令处理的元素越多，但 32 个物理向量寄存器的预算是硬约束——LMUL=8 时一个向量寄存器组占用 8 个物理寄存器。前述系统评测在同一平台测得，超出寄存器预算触发 spill 后性能下降 8-18 倍，是 LMUL 参数错误中惩罚最重的一项；该数字为评测结果而非通用结论，不同微架构的 spill 代价差异很大。作为参考，该评测中 LMUL=4 配合 4-6 组独立累加器处于安全区间，具体最优配置仍取决于内核结构与目标硬件。
一篇对 GCC 15/LLVM 21 在 RVV 1.0 硬件上的系统评测给出了两条值得参考的微基准数据：掩码方式处理尾部元素相比 vsetvli 设置 VL 存在约 35% 的固定开销；自动向量化对 DGEMM 这类复杂内核的生成代码效率仍低——手写 RVV 内在函数（vsetvl + vle64 + vfmacc）的朴素移植即可获得 12 倍于标量的性能。需要说明的是，这两组数字来自该评测的特定编译器版本与硬件组合，不同工具链和核上的表现会有差异，只能作为量级参考。其指向的结论具有普遍性：自动向量化适合规则简单循环，计算密集内核依赖 RVV intrinsics 手工优化仍是当前主流实践。
glibc 层面，memcpy/memset/memcmp 的 RVV 优化近两年已陆续回合上游，采用 vsetvli 自适应循环处理尾部。实际收益取决于运行平台的 RVV 实现效率，不能直接套用 x86 上 SIMD 字符串函数的经验。
三、内存调优：对齐、预取与缓存块操作
非对齐访问
RISC-V 非对齐访问行为由 PMA（Physical Memory Attributes）决定，不同实现差异极大——有的核拆成多次对齐访问，有的直接陷入异常模拟。优化前先用 riscv_hwprobe 查询 MISALIGNED_FAST。对热数据结构进行适当对齐可以减少跨 cache line 或访问边界带来的额外开销，但具体对齐值应根据目标处理器的 cache line 和内存层次结构确定，不应默认所有 RISC-V 平台均采用 64 字节 cache line；LLVM 编译时可用 -mno-strict-align 控制是否生成非对齐访存指令，默认行为依 -mcpu 目标的微架构特性而定。
CBO 扩展：软件可控的缓存块操作
RISC-V CMO 规范定义了 Zicbop、Zicboz 和 Zicbom 等缓存块操作扩展，Linux RISC-V 内核已提供相应的 ISA 探测和支持：
扩展 | 指令 | 用途 |
Zicbop | PREFETCH.R / W / I | 软件预取，编译器可将 __builtin_prefetch 映射到该指令 |
Zicboz | CBO.ZERO | 整缓存块清零，可用于优化满足对齐和大小条件的批量清零操作 |
Zicbom | CBO.CLEAN / INVAL / FLUSH | 缓存维护，主要用于非一致 DMA 场景 |
软件预取对规则步进访问且延迟敏感的循环（如流式处理）有效；乱序核的硬件预取通常已覆盖顺序模式，盲目插入 prefetch 指令反而污染缓存。预取收益需以 perf 的 cache-miss 事件验证。
数据布局与 TLB
●
AoS → SoA：对于需要连续处理同一字段的大规模向量计算，SoA 通常更有利于形成连续访存和高效向量化；但 AoS 并非不能向量化，RVV 可利用 segment load/store 机制处理交错数据布局，LLVM 也提供 vector interleave/deinterleave intrinsic 用于表示和优化交错数据的向量操作。
●
Hugepage：大内存 footprint 的应用（数据库、大模型推理）开启透明大页（THP，内核 CONFIG_TRANSPARENT_HUGEPAGE，RISC-V 主线已支持）可显著降低 TLB miss 率，这一优化与架构无关但在 RISC-V 平台上同样有效。
四、性能分析方法
优化前先定位瓶颈，RISC-V 上的工具现状：
●
perf：依赖核实现的 PMU 事件（cycle/instruction 基本可用，cache/branch 事件依实现而定）。perf 计数器语义由具体 PMU 实现定义，使用前可通过已知指令数的微基准校准计数器，确认计数结果与预期一致；具体误差范围取决于 PMU 实现和测量方式。Sscofpmf 扩展（采样溢出与过滤）支撑 perf 的采样模式，新内核已支持。
结语
RISC-V 性能优化的工作量分布大致是：编译器目标配置（-mcpu + LTO）通常是成本最低的改进起点；RVV 向量化面向计算密集内核；内存调优（对齐、布局、预取）面向带宽受限场景。各环节的实际收益高度依赖具体 workload 与目标硬件，前文引用的评测数字只能作为量级参考，不应作为普遍预期。三者的共同前提是可用的测量工具——riscv_hwprobe 查平台特性、编译器 remark 验证向量化、perf/TMAM 定位瓶颈，跳过测量直接调参是性能工作最常见的弯路。
