编者按：RISC-V 生态繁荣离不开编译器工具链演进。玄铁团队持续推进 RISC-V 后端在上游社区及龙蜥、如意等主流操作系统社区的功能支持与性能优化。在近期举办的 RISC-V 编译器生态和性能优化 MeetUp上，阿里巴巴达摩院高级技术专家、玄铁 RISC-V 开发工具负责人尚云海分享了《RISC- V 编译器的优化进展》。他围绕指令集功能支持与性能优化两大方向，剖析当前支持状态及与其他架构的差距，并分享了玄铁最新成果：后端层面开启高效指令 fusion 优化，中端层面通过循环变换、自动向量化决策提升编译质量，为 RISC-V 生态发展提供坚实的工具链支撑，助力产业落地。以下为本次分享全文：
玄铁团队自 2001 年起深耕处理器领域，2017 年全面转向 RISC-V，同年加入 RISC-V 国际基金会并成为董事会成员，随后快速发布首款处理器核 E902。2018 年推出当时性能最强的 C910，2019 年实现全球首个 RISC-V 安卓系统。2021 年，团队与龙蜥社区合作，曳影 1520 首次兼容龙蜥操作系统并成功运行，此后国内 RISC-V 生态迅速升温，钉钉等多款 OS 和应用相继完成适配。今年推出的高性能旗舰处理器 C950 单核性能提升超 70%，标志着 RISC-V 正式进入服务器市场。经过多年发展，玄铁已形成完整的处理器产品系列。目前累计出货超 45 亿颗，服务 900 余家客户。
编译器生态建设思路
在编译器生态建设方面，尚云海阐述了三条核心思路。
Follow RISC-V 指令集标准，做强生态
团队在 RISC-V 基金会及工作组上投入了大量精力。今天看到的很多RISC-V标准扩展指令的设计思路，与早期玄铁扩展指令有着异曲同之妙，团队希望通过自身对行业的实践，把指令集标准不断做强。
同时，指令集不是凭空想象出来的，必须以当代典型应用负载驱动。RISC-V 原来的基础指令集只有四十多条，要适配、搞定各种各样的场景理论上就存在困难。因此近些年的发展中，在精简指令集的基础上，面向各类场景领域加入各类扩展指令集。在面向高性能的 DataCenter 计算和智能计算场景，团队也发现了很多问题并在积极解决中，同时也不断向上游贡献中。
基于主流编程语言、主流框架优化，方便业务落地
尚云海表示，团队坚决地把主流编译器做好，包括 LLVM、GCC、C/C++、Rust、Go 等，主要目标是让 RISC-V 编译器及相关工具，开发者用起来便利，在产业应用落地上受欢迎，。团队不断更新版本到最新，同时把优化内容反馈回上游。
操作系统生态：以实践检验编译器
编译器优化做得再多，真正的检验还是要看实践。团队秉承这一理念，将编译器推到龙蜥、如意等社区中去，由真实的应用来检验编译器的优化点，RISC-V 指令集的优化点。从两大编译器（GCC 和 LLVM）在 OS 中的落地情况来看，功能支持基本完善，但在很多新的业务场景上仍有很多改进空间。
GCC 后端技术问题与解决方案
尚云海结合近期在 GCC 上的实践，重点分享了五个技术问题及其解决思路。
指令融合（Instruction Fusion）框架
GCC 的 RISC-V 后端目前缺少一个通用的指令融合框架。和大家一样，出发点是想把自家的硬件（玄铁 950）性能提上去。但与社区交流后发现，应该做一套通用的指令融合框架。
具体做法包括：把常见的 Fusion 优化机制做成一个通用库，方便开发者调用；新处理器加入时，只需通过简单的 config 配置就能实现优化功能；同时把寄存器依赖分析、地址依赖相关分析等写成通用函数，供各个硬件后端复用。这套框架内部已基本完成，预计 GCC 17 版本中合入。
RISC-V 自动向量化决策优化
当前 GCC 对 RISC-V 的自动向量化决策不够精细。实测发现，自动向量化后性能可能与手动优化差不多，甚至更差，某些情况下还会出现劣化。主要原因在于整个向量化的代价决策模型还很粗糙。
团队的解决方案是加入更细致的代价判断：包括向量寄存器压力、指令调度压力等因素；同时排除不适合向量化的场景（如存在复杂依赖关系的代码）；对于大循环而言，向量化通常有正向收益，但对小循环，特别是 Vector的头部尾部处理等，需要更精细的代价模型。
向量配置 vsetvl 消除优化
与传统 SIMD 编程不同，在编程中向量长度是在编译期固定的，转换相对直接。RISC-V Vector 编程的向量长度在运行时动态配置，具有高度灵活性，但这种灵活性也给编译器带来了优化难题。
在自动向量化过程中，编译器需要反复插入 vsetvl 指令来调整向量长度和计算方式。由于每次向量化操作都涉及向量基本单元的重新配置，生成的代码中往往出现大量 vsetvl 指令。仔细审视便会发现，有很大一部分是冗余的，前面已经完成的配置，在后续代码中又会被重复设置。
传统的编译器优化基本局限于单个 block 块，对跨函数的 vsetvl 冗余并未涉及。团队的思路是将优化范围从单 block 到整个函数，使整个函数的冗余 vsetvl 得以有效消除；对于相邻的重复 vsetvl 设置，则通过死代码消除（DCE）等手段予以合并或去除。
TLS 变量访问性能问题
在多线程场景中，TLS（Thread-Local Storage）变量的使用非常常见。传统做法下，每次访问 TLS 变量都需要通过标准函数调用来获得变量地址，这会导致caller save 寄存器被破坏，并产生 Spill 行为，一来一回产生较大的性能开销。
目前更优的做法是 TLS Description，在 RISC-V ABI 规范中已有定义，但实现机制尚有缺失，包括在静态库、动态链接器和编译器中都还支持不完善。团队实现了从编译器到动态链接器的完整 TLS Description 机制支持，具体到真实应用，测试下来大概有 10% 的性能提升。
循环优化缺少后端接口
循环优化（特别是循环展开）对性能影响较大。原来的循环优化机制只是简单地决定展开或不展开，没有很好的后端接口。但展开次数太多会导致代码膨胀，对小 Cache 的处理器反而带来性能负增长。
团队给循环展开加了一个后端接口，由后端根据目标处理器的流水线深度、Cache 大小、预取行为等硬件特性来具体决定循环展开策略（比如展开 4 次、5 次还是 8 次）。实测下来，在该框架下的循环展开性能收益趋于稳定。
上游贡献总览
团队在开源生态建设方面成果显著，累计向 GCC、LLVM、glibc、Binutils 等 6 个核心上游仓库提交 Patch 超 200 个，并拥有 3 位仓库 Maintainer。团队率先将二进制优化工具 BOLT 支持 RISC-V 后端，实现了全流程跑通。BOLT 属于后链接优化器而非传统静态编译器，其能够基于运行时动态分析进行精确优化，对未来高性能处理器至关重要。目前，该工具在 x86 和 ARM 平台上均已验证可带来显著的性能收益，RISC-V 通过该工具预计也能得到较好收益。
在 OS 社区方面，团队在龙蜥、如意等社区做了大量贡献，包括 GCC、Binutils、Linux Kernel 等关键组建，并得到了社区的认可。2022 年，达摩院、阿里云协同 PLCT 实验室、统信软件发布 Anolis OS 8 for RISC-V 预览版，行业首个支持玄铁 C910 的 RISC-V 开源操作系统版本。2025 年，达摩院牵头完成 2000+ RISC-V 系统软件包构建，并发布 Anolis OS 23.3 for RISC-V 预览版。2026 年，达摩院、阿里云等共建支持 RVA23 Profile 的 Anolis OS 23.4 RISC-V 正式版本。
未来探索方向
尚云海在演讲最后分享了几个正在探索的方向：
第一，商业编译器的优化特性引入。很多商业编译器里已经实现的优秀优化机制，但在开源社区中缺少实现。团队希望把这些好的优化机制吸收到开源编译器中，特别是数据布局优化、局部性优化等，对高性能处理器非常有效。
第二，代价模型的 ML 化探索。传统代价模型对于复杂流水线（如六发射、超大发射窗口、乱序执行）往往不准确。团队尝试用 AI 模型来取代传统的代价模型：通过在真实硬件上跑数据，让模型自动学习指令代价，取代人工定义的代价模型。
第三，BOLT 优化能力的进一步增强。团队认为 BOLT 对未来高性能处理器非常重要，计划继续加强其优化能力。
第四，向量化的深入探索。各家都在把向量单元做得越来越宽，如何充分利用这些向量指令是值得研究的问题。市面上看到 1024bit、2048bit、4098bit 位宽的硬件不断被推出，相对于标量有 32 倍(1024/32）的计算位宽提升。因此，软件层面的向量化优化空间巨大。
最后，希望玄铁与业界保持更紧密的交流与协作，共同推动 RISC-V 软件生态走向成熟。
本次 MeetUp PPT 、视频回放已上线龙蜥官网，欢迎点击查看：
PPT 下载链接：
https://docs.openanolis.cn/document/detail/rpzigrnb
视频回放：
https://openanolis.cn/video/#1658313779883670231
—— 完 ——
