山东大学RISC-V公共开放平台开发记录3

山东大学RISC-V公共开放平台开发记录

RISC-V编译

2 编译优化策略

2.1 RISC-V GCC工具链的（–mcmodel=）选项

目前RISC-V GCC工具链认为，在实际的情形中，一个程序的大小一般不会超过4GB的大小，因此在程序内部的寻址空间不能超过4GB的空间。而在64位的架构中，地址空间的大小远远的大于4GB的空间，因此针对RV64架构而言，RISC-V GCC工具链定义了（–mcmodel=）选项用于指定寻址范围的模式，使得编译器在编译阶段能够按照相应的策略编译生成代码。其有效的选项值如下：

· -mcmodel=medlow

· -mcmodel=medany

注意：

· 在RV32架构中，整个地址空间的大小就是4GB，因此（–mcmodel=）选项的任何值对于编译的结果都无影响。

· RISC-V GCC工具链在未来可能也会支持大于4GB的寻址空间。

medlow和medany两个选项的含义分别解释如下。

1.（-mcmodel=medlow）选项

（-mcmodel==medlow）选项用于指示该程序的寻址范围固定只能在-2GB至+2GB的空间内。注意：地址区间没有负数可言，-2GB是指整个64位地址空间最高2GB地址区间。
由于此模式的寻址空间是固定的-2GB至+2GB的空间内，因此编译器能够相对生成比较高效的代码，但是由于寻址空间固定，对于整个64位的大多数地址空间都无法访问到，用户需小心使用。

2.（-mcmodel=medany）选项

（-mcmodel==medlow）选项用于指示该程序的寻址范围可以在任意的一个4G空间内。由于此模式的寻址空间不是固定的，所以相对比较灵活。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ByJOEYsP-1654330904936)(file:///C:/Users/Jeremiah/AppData/Local/Temp/msohtmlclip1/01/clip_image002.gif)]

2.2 SIFIVE的解决方案

为了确保RISC-V编译器的命令行界面在未来易于扩展，SIFIVE决定采用这样一种方案：用户用三个参数来描述他们要编译的RISC-V目标。

-march=ISA选择目标架构。这将控制哪些指令和寄存器可供编译器使用。

-mabi=ABI 选择目标ABI。这控制了调用惯例（哪些参数在哪些寄存器中传递）和内存中的数据布局。

-mtune=CODENAME选择目标的微架构。这将告知GCC每条指令的性能，使其能够执行针对目标的优化。

-march参数

-march参数基本上是由RISC-V用户级ISA手册定义的。-march控制指令集，允许编译器从中生成指令。这个参数决定了一个程序可以运行的实现集：任何符合RISC-V标准的系统，只要包含了用于编译程序的-march值，就应该能够运行该程序。

说得更具体一点。RISC-V用户级ISA的2.2版本定义了目前工具链支持的三种基本ISA。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RYrhKdv3-1654330904938)(file:///C:/Users/Jeremiah/AppData/Local/Temp/msohtmlclip1/01/clip_image002.gif)]

参数-mabi

GCC的-mabi参数指定了生成的代码所符合的整数和浮点ABI。就像-march参数指定了生成的代码可以在哪些硬件上运行一样，-mabi参数指定了生成的代码可以与哪些软件链接。我们使用整数ABI的标准命名方案（ilp32或lp64），并附加一个参数单字母来选择ABI使用的浮点寄存器（ilp32 vs ilp32f vs ilp32d）。为了使对象能够被链接在一起，它们必须遵循相同的ABI。

RISC-V定义了两个整数ABI和三个浮点ABI，它们一起被视为一个ABI字符串。整数ABI遵循标准ABI命名方案。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RLPs15Y6-1654330904939)(file:///C:/Users/Jeremiah/AppData/Local/Temp/msohtmlclip1/01/clip_image004.gif)]

就像ISA字符串一样，ABI字符串被串联起来，并通过-mabi参数传递给GCC。为了解释为什么ISA和ABI应该被当作两个独立的参数，让我们来看看少数几个-march/mabi的组合。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uymHNWeX-1654330904939)(file:///C:/Users/Jeremiah/AppData/Local/Temp/msohtmlclip1/01/clip_image006.gif)]

-mtune参数

在指定目标时涉及的最后一个编译器参数是最简单的。虽然-march参数会导致系统无法执行代码，-mabi参数会导致对象之间的不兼容，但-mtune参数应该只改变生成代码的性能。就目前而言，我们确实没有任何针对RISC-V系统的调谐模型。除非你刚刚给我们的GCC端口添加了一个新的调谐参数，否则你可能不应该费力地对这个参数做什么。

2.3 GCC优化

RISC-V是一个新的开源指令集架构(ISA)，在2016年12月生产了第一批量产处理器。

2016年9月，它制造了第一批大规模生产的处理器。它的重点是

它专注于经济性和性能，与其他开源架构不同的是

架构的不同之处在于，它没有一个允许供应商自由设计、生产和销售RISC-V的版权许可。

签署、制造和销售RISC-V芯片而不需要任何费用，也不需要分享他们对参考实现的修改。

他们对架构的参考实现的修改。

本论文的目标是评估GCC和LLVM/clang编译器的性能。

本论文的目的是评估GCC和LLVM/clang编译器对RISC-V目标的支持性能以及它们为该架构进行优化的能力。优化架构的能力。性能的评估将从CoreMark和Dhrystone中进行。

性能将从CoreMark和Dhrystone进行评估，这两个都是流行的工业标准这，用于评估嵌入式处理器的性能的基准。它们将在GCC和LLVM/clang编译器上以不同的优化水平运行。

级别上运行，并与ARM架构的每时钟性能进行比较。与RISC-V相比，ARM架构更加成熟，但也是最类似的广泛使用的CPU架构。对RISC-V目标的编译器支持仍在开发中。

的编译器支持仍在开发中，本论文的重点将是目前GCC与RISC-V的性能差异。

GCC和LLVM编译器在这个架构上的差异。结果显示，GCC上的-O2和-O3优化级别的-O2和-O3优化水平与我们的ARM参考相比表现非常好。在较低的-O1优化级别和-O0（没有优化）以及-O，也就是带有优化的-O0，以生成更小的可执行代码大小。CoreMark基准测试中，GCC在-O1时的性能为46%，在-Os时为8.2%，在-O0时为9.3%，结果相似。

在Dhrystone中，除了在-O1上的表现与ARM一样好之外，GCC的表现比ARM差很多。，RISC-V的GCC在CoreMark中的性能是ARM的9.2%，在Dhrystone中的性能是ARM的11%。在CoreMark中的性能是ARM的9.2%，在Dhrystone中是11%，另一方面，LLVM/clang在试图编译我们的CoreMark基准时崩溃了。而在Dhrystone上，优化选项的影响非常小。

而在Dhrystone上，优化选项对性能的影响非常小，它的性能是GCC的6.0%。

在Dhrystone上，优化选项对性能的影响很小，使其在-O3上的性能是GCC的6.0%，在-O3上的性能是ARM的5.6%，所以即使有优化，它仍然比没有优化的GCC慢。

总而言之，考虑到RISC-V与GCC编译器在较高的优化水平上的表现，RISC-V的性能非常好。RISC-V架构是如此年轻。然而，在较低的优化水平上确实有改进的余地。这也可能会提高高优化级别的性能。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JEoUiJSA-1654330904940)(file:///C:/Users/Jeremiah/AppData/Local/Temp/msohtmlclip1/01/clip_image008.gif)]

在较高的优化级别上，GCC的表现确实相当好，例如-O3和-O2，但在较低的优化水平上似乎有一些问题。而较高的优化级别表现良好，由于性能在生产中是最重要的

，你可以认为GCC的支持对于生产来说已经足够快了，但是当在汇编级别上进行调试时

级别的调试时，或者你在开发过程中需要更快的编译时间时，可以考虑使用GCC。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-a9sfWEqr-1654330904941)(file:///C:/Users/Jeremiah/AppData/Local/Temp/msohtmlclip1/01/clip_image010.gif)]

RISC-V上的GCC在较高的优化水平上表现非常好，但在较低的优化水平上则明显较慢。但在较低的优化水平上却明显地慢了下来。-O1优化比Dhrystone的-O0快16.6倍，这在其他架构上是不正常的。但更高的优化级别，如-O2和-O3对于这样一个年轻的架构来说，非常有竞争力，令人印象深刻。架构来说是相当了不起的。

2.4系统级优化

l 处理器利用率提升

处理器中的性能优化主要体现在其利用率的提升。处理器利用率反映了处理器有效工作时间在总运行时间中的占比,是一项描述处理器繁忙程度的指标。减少处理器空闲等待的时间,提升处理器利用率,将推动系统整体的计算能力或数据处理能力的提升,使系统能够在更短时间内完成既定工作,或者在相同时间内完成更多工作。

“冯·诺依曼瓶颈”是影响 CPU 利用率的一类典型问题。在冯·诺依曼结构[79]的计算机系统中,指令与数据被不加区分地存放在内存,使得取指令和数据不能同时进行,否则将引起访存混乱。CPU 在执行运算前后,都需要额外的时间等待数据完成存取,而不能一直处于工作状态。因此,冯·诺依曼结构中的 CPU 存在一个相对较低的利用率上限,无论硬件制造工艺如何提升,都无法再获得更高的 CPU 利用率。

相应地,在 2017 年,包云岗等人提出一种标签化冯·诺依曼体系结构 LvNA(labeled von neumann architecture),在经典冯·诺依曼结构上增加了一套基于标签机制的可编程接口,允许向硬件传递更多软件信息,使硬件可以根据软件需求动态调整管理策略。2019 年,该团队主导的“标签化 RISC-V”开发项目,基于RISC-V Rocket Chip 实现了 LvNA,显示了 RISC-V 在促进敏捷开发、提升编码效率方面的优势。在 2021 年, Schuiki 等提出了一种轻量级的 RISC-V 扩展“流语义寄存器(stream semantic registers,简称 SSR)”,允许在任何指令中编码加载和存储操作,而不再需要依赖显式的加载与存储指令,从而给出了一种解决单发射处理器中存在“冯·诺依曼瓶颈”、影响 CPU 利用率问题的方案。实验结果显示,采用 SSR 扩展的处理器比起未采用的相同处理器,顺序代码单核心运行速度提升 3 倍,即,集群中实现相同的性能可减少 3 倍的核心数目;多核心集群的

能效提高 2 倍,指令获取的数量减少 3.5 倍,指令缓存功耗减少 5.6 倍。

l 内存优化

内存的设计直接制约着系统整体的组织形式和工作方式,在数据存储、通信、同步、处理效率等多方面都对系统有关键性的影响。因此,内存优化问题始终是系统性能研究的一大重点。

例如,多核处理器中,随着芯片上核心数量的增加,会出现“缓存行乒乓”问题,即,当多个 CPU 共享同一缓存行中的变量时,不同 CPU 对该变量的频繁读写会导致其他 CPU 的缓存行频繁失效。共享内存中,硬件缓存一致性范式的线程同步算法,其性能扩展问题会受到缓存行乒乓的阻碍。2019 年,Dogan 等人为了解决多核处理器的缓存行乒乓问题,提出了一种针对数据的硬件内移动计算(moving computation,简称 MC)模型,该模型将共享数据固定在专用核上,以实现数据局部性优化。研究人员还在 RISC-V 上建立了多核仿真环境,评估了 MC 模

型在最多 1024 核尺度下的性能扩展优势。评估结果显示,与自旋模型、原子模型等现有模型相比,对每个数据点标准化的完成时间平均分别提升了 60%、27%。

扩展基全局地址空间(extended base global address space,简称 xBGAS)是 2018 年 Leidel 等人为了解决可扩展的高性能计算架构在操作离开单个设备域时常常遭遇不必要的延迟的问题,所提出的一种 RISC-V 指令集微架构扩展。该扩展可以为常见的高性能计算操作提供紧耦合的支持。由于其提供了从基本指令访问全局共享内存地址空间的可能性,从而开创了一条系统优化的新思路,出现了更多以 xBGAS 为基础的研究。

例如,2019 年 Williams 等人在 xBGAS 的基础上,提出了一种构建集体通信库的 RISC-V 微架构扩展方案,给出了它的初始 API 设计和实现,以及底层算法。这项研究的目的是在分布式地址空间模型中,将更直观的界面与更高的性能结合起来,以解决软件开发人员很难适应并行编程方法,尤其是分布式地址空间中的并行编程问题。

2020 年 Wang 等人提出了一种远程原子扩展(remote atomic extension,简称 RAE)的设计,为基于 RISC-V SA 架构的远程原子操作提供了内在的 ISA 级指令和架构支持,以改善高性能计算(high performance computing,简称 HPC)系统的性能。

l 通信延迟缓解

通信是连接系统各组件、各成分之间的信息交换过程,通信延迟将推迟目标获得所需信息的时间,从而增大其空闲等待时间,造成整体用时延长、目标利用率降低、或者能量空耗。缓解通信延迟,除了期待相关硬件制作工艺的改进外,提升系统的并行能力、掩盖通信延迟的不利影响也是一种可行的做法。

)系统的性能。

l 通信延迟缓解

通信是连接系统各组件、各成分之间的信息交换过程,通信延迟将推迟目标获得所需信息的时间,从而增大其空闲等待时间,造成整体用时延长、目标利用率降低、或者能量空耗。缓解通信延迟,除了期待相关硬件制作工艺的改进外,提升系统的并行能力、掩盖通信延迟的不利影响也是一种可行的做法。

这方面,Morais 等人在 2019 年提出了一种将任务调度硬件加速器与通用 CPU 紧密集成的体系结构,以减少通信延迟及运行开销,从而提高与任务调度并行的应用程序的性能。他们开发了硬件加速的轻量级任务调度运行时环境 Phentos,允许任务调度软件通过自定义指令与硬件任务调度器和CPU直接进行交互,以最大限度减少硬件任务调度器和 CPU 之间的通信开销。Morias 等人认为,任务并行系统的性能会受到自动依赖推理和准备运行任务调度相关开销的限制,而用于提高运行时性能的硬件加速器往往具有较高的 CPU 通信开销,因此他们希望通过这样的设计,来解决 CPU 通信的高开销问题。