发射调度器

本小节解析现代 NVIDIA GPU 的发射调度器。我们先在 小节 5.1.1 中描述每周期哪些 warp 会被视为“可发射”，再在 小节 5.1.2 中说明选择策略。

前端

根据 NVIDIA 多份文档中的 SM 结构图[19], [20], [21], [22], [23], [24], [25]，SM 包含四个 sub-core，warp 以轮转方式分配到 sub-core（即 warp ID mod 4）[32], [33]。每个 sub-core 有私有 L0 指令缓存，并连接到全 SM 共享的 L1 指令缓存。我们假设存在仲裁器协调多个 sub-core 的请求。

每个 L0 ICache 都有指令预取器[44]。我们的实验印证了 Cao 等人关于 GPU 指令预取有效性的结论[45]。尽管我们无法确认 NVIDIA 的具体实现，但推测为类似流缓冲的简单方案[46]，即在 miss 发生时预取后续连续的缓存行。基于分析，我们假设流缓冲大小为 16（见 小节 7.3）。

我们无法通过实验确认精确的取指策略，但若其与发射策略差异过大，将频繁出现“指令缓冲区无有效指令”的情况，而我们并未观察到这一现象。因此，我们假设每个 sub-core 每周期可取指并译码 1 条指令。取指调度器优先从上次（或最近一次）发射指令的 warp 取指，除非该 warp 的指令缓冲区中已存在的指令数加上在途取指数达到缓冲区容量。此时调度器切换到指令缓冲区有空位的最年轻 warp。我们假设每个 warp 有 3 个指令缓冲区条目，足以支撑“贪心发射”策略，因为从取指到发射有 2 个流水阶段。如果缓冲区仅有 2 项，贪心策略将被破坏：例如在所有请求 ICache 命中、所有 warp 缓冲区均满的情况下，若第 1 周期发射 W1 同时取指 W0，第 2 周期将发射 W1 的第 2 条并取指第 3 条；第 3 周期 W1 的第 3 条仍在译码中，缓冲区无有效指令，贪心策略失败，被迫切换 warp。3 项缓冲区可避免该问题，这与我们的实验一致。多数文献假设取指/译码宽度为 2 且缓冲区为 2 项，并且只有当缓冲区为空才取指，这会导致每两个连续指令后就切换 warp，与我们的观察不符。

寄存器文件

我们通过大量实验（不同 SASS 指令组合、不同寄存器文件端口压力、是否使用寄存器文件缓存）来揭示寄存器文件组织。

现代 NVIDIA GPU 具有多种寄存器文件：

• 常规寄存器（Regular）：最近架构每个 SM 有 65536 个 32 位寄存器[19], [20], [21], [22], [23]，用于保存线程计算值。寄存器按 32 个为一组，对应 warp 中 32 个线程，形成 2048 个“warp 寄存器”。寄存器在 sub-core 间均匀分布，每个 sub-core 的寄存器文件分成两个 bank[32], [33]。每个 warp 可使用 1 至 256 个寄存器，编译时确定。每 warp 使用寄存器越多，SM 并行 warp 数越少。
• 统一寄存器（Uniform）：每个 warp 有 64 个私有 32 位寄存器，用于保存该 warp 所有线程共享的值[33]。
• 谓词寄存器（Predicate）：每个 warp 有 8 个 32 位寄存器，每个 bit 对应 warp 中一个线程，用于指示是否执行指令及分支走向。
• 统一谓词寄存器（Uniform Predicate）：每个 warp 有 8 个 1-bit 寄存器，用于全 warp 共享的谓词。
• SB 寄存器：每个 warp 有 6 个“依赖计数器”寄存器，用于追踪可变延迟依赖（见 小节 4）。
• B 寄存器：每个 warp 至少有 16 个 B 寄存器用于控制流重汇合（re-convergence）[47]。
• 特殊寄存器：用于存放线程 ID、block ID 等特殊值。

与以往假设存在 operand collector 以处理寄存器端口冲突的工作不同[13], [15], [48]，现代 NVIDIA GPU 并未使用 operand collector。若使用 collector，会引入发射到写回的可变延迟，使得 NVIDIA ISA 的固定延迟无法在编译期确定，无法正确依赖管理（见 小节 4）。我们通过多组生产者—消费者指令序列的实验验证了 collector 的不存在：无论寄存器端口冲突数量如何，停顿计数器所需值与指令执行时间均保持不变。

实验显示，每个寄存器文件 bank 有一个 1024-bit 专用写端口。此外，当一条 load 指令与一条固定延迟指令在同周期完成时，被延迟的是 load 指令；而当两个固定延迟指令（如 IADD3 与 IMAD）写同一 bank 时，两者都不延迟。这表明固定延迟指令使用了类似 Fermi 中引入的结果队列[49]。其消费者不被延迟，说明存在旁路（bypass）以在写回前转发结果。

在读方面，我们观察到每 bank 1024-bit 带宽。通过连续 FADD、FMUL、FFMA 指令测得这一结果。¹

例如，当 FMUL 的两个源操作数来自同一 bank 时会产生 1 个周期气泡；若来自不同 bank 则无气泡。FFMA 的三个源操作数都在同一 bank 时会产生 2 个周期气泡。

我们未能找到一个完全匹配所有案例的读端口仲裁策略，因为气泡生成还依赖指令类型与操作数角色。最接近实验结果的模型为：固定延迟指令在发射与读操作数之间有两个中间阶段 Control 与 Allocate（见 小节 5.1.1）。Allocate 负责保留寄存器文件读端口；每 bank 有一个 1024-bit 读端口，并通过寄存器文件缓存缓解读冲突。实验显示所有固定延迟指令读取操作数会持续 3 个周期，即便某些周期空闲（例如仅有两个源操作数），因为 FADD 与 FMUL 的延迟与 FFMA 相同，而 FFMA 不论三操作数是否在同一 bank 延迟都相同。若指令在 Allocate 阶段发现无法在后续三周期内读取完所有操作数，则其被阻塞在该阶段并向上游施加气泡，直到能够预留所需端口。

# 寄存器文件缓存行为示例
# Example 1
IADD3 R1, R2.reuse, R3, R4 # Allocates R2
FFMA R5, R2, R7, R8 # R2 hits and becomes unavailable
IADD3 R10, R2, R12, R13 # R2 misses

# Example 2
IADD3 R1, R2.reuse, R3, R4 # Allocates R2
FFMA R5, R2.reuse, R7, R8 # R2 hits and is retained
IADD3 R10, R2, R12, R13 # R2 hits

# Example 3. R2 misses in the second instruction since it is
# cached in another slot. R2 remains available in the first
# slot since R7 uses a different bank
IADD3 R1, R2.reuse, R3, R4 # Allocates R2
FFMA R5, R7, R2, R8 # R2 misses
IADD3 R10, R2, R12, R13 # R2 hits

# Example 4. R2 misses in the third instruction since the
# second instruction uses a different register that goes to
# the same bank in the same operand slot
IADD3 R1, R2.reuse, R3, R4 # Allocates R2
FFMA R5, R4, R7, R8 # R4 misses and R2 becomes unavailable
IADD3 R10, R2, R12, R13 # R2 misses

内存流水线

现代 NVIDIA GPU 的内存流水线包含每个 sub-core 本地的初始阶段，而实际访存的后续阶段由四个 sub-core 共享，因为数据缓存与共享内存为 SM 共享结构[24], [25]。本节揭示每个 sub-core 的 load/store 队列大小、sub-core 向共享结构发送请求的速率，以及不同内存指令的延迟。

注意内存访问分为两大类：共享内存访问（SM 内部、线程块共享）与全局内存访问（GPU 主存）。

为了确定队列大小与内存带宽，我们进行了一系列实验，每个 sub-core 要么执行一个 warp，要么空闲。每个 warp 执行一串相互独立的 load/store 指令，这些指令始终命中数据缓存或共享内存，并使用常规寄存器。表 1 展示实验结果。第一列为指令序号，其余四列为不同活跃 sub-core 数量下该指令的发射周期（每格按周期升序列出所有活跃 sub-core）。

指令编号	活跃 sub-core 数 = 1	活跃 sub-core 数 = 2	活跃 sub-core 数 = 3	活跃 sub-core 数 = 4
1	2	2/2	2/2/2	2/2/2/2
2	3	3/3	3/3/3	3/3/3/3
3	4	4/4	4/4/4	4/4/4/4
4	5	5/5	5/5/5	5/5/5/5
5	6	6/6	6/6/6	6/6/6/6
6	13	13/15	13/15/17	13/15/17/19
7	17	17/19	19/21/23	21/23/25/27
8	21	21/23	25/27/29	29/31/33/35

可以看到，在 Ampere 中每个 sub-core 可连续 5 条内存指令按每周期一条发射，第 6 条指令的发射会产生停顿，且停顿周期取决于活跃 sub-core 数量。这表明每个 sub-core 可无阻塞地缓冲 5 条指令，而全局共享结构可每两周期从任一 sub-core 接收一个内存请求。观察多 sub-core 情形可知：第 6 条及之后的指令在每个 sub-core 上以两周期间隔发射。

我们还可推断 sub-core 中的地址计算吞吐率为每 4 周期一条指令：当只有一个 sub-core 活跃时，第 6 条指令之后出现 4 周期间隔。两 sub-core 活跃时，由于共享结构吞吐率为每 2 周期一条，故每个 sub-core 可每 4 周期发射一条；更多 sub-core 活跃时共享结构成为瓶颈。例如四 sub-core 活跃时，每个 sub-core 只能每 8 周期发射一条，因为共享结构最大吞吐为每 2 周期一条。

关于每个 sub-core 内存队列大小，我们估计为 4，尽管每个 sub-core 可缓冲 5 条连续指令。指令进入单元时占用槽位，离开单元时释放槽位。

我们测量了不同内存指令在缓存命中且单线程执行时的两类延迟。第一类是从 load 发射到消费者或覆盖同一目的寄存器的指令可以发射的最早时间（RAW/WAW 延迟；store 不产生寄存器 RAW/WAW）。第二类是从 load/store 发射到能够写入其源寄存器的指令可发射的最早时间（WAR 延迟）。结果见 表 2。

我们观察到：使用统一寄存器计算地址的全局内存访问比使用常规寄存器更快，因为前者所有线程共享同一地址，仅需计算一个地址，而后者每线程可能不同。

共享内存 load 的延迟低于全局内存。其 WAR 延迟对常规与统一寄存器相同，而 RAW/WAW 延迟在统一寄存器时少 1 个周期。这表明共享内存的地址计算在共享结构中完成，WAR 依赖在源寄存器读取后即可解除。

如预期，延迟也受访问粒度影响。对于 WAR 依赖，load 延迟不随数据大小变化，因为源操作数仅用于地址计算且大小固定；对于 store，写入数据也是源操作数，数据越大 WAR 延迟越高。RAW/WAW 依赖（仅适用于 load）随数据大小增大而增大，因为需要更多数据传输到寄存器文件。我们测得该传输带宽为每周期 512 bit。

此外，常量缓存的 WAR 延迟显著高于全局内存 load，而 RAW/WAW 延迟略低。我们尚无法给出合理解释。但我们发现，固定延迟指令访问常量空间使用不同的缓存层级：通过 LDC 预加载常量地址并等待完成后，再发射使用同一常量地址的固定延迟指令，会出现约 79 周期的 miss 延迟，而非命中。这表明固定延迟指令访问常量空间使用 L0 FL（固定延迟）常量缓存，而 LDC 指令使用 L0 VL（可变延迟）常量缓存。

最后，我们分析 LDGSTS 指令，该指令用于减少寄存器文件压力并提升数据传输效率[55]。它从全局内存加载数据并直接写入共享内存，绕过寄存器文件，节省指令与寄存器。其延迟与指令粒度无关。WAR 依赖在地址计算完成后解除；RAW/WAW 依赖在读阶段完成后解除。

方法

我们通过将模拟器结果与真实 GPU 的硬件计数器指标进行对比来验证准确性。使用了四种 Ampere GPU[21]（规格见 表 4），CUDA 版本为 11.4，NVBit 为 1.5.5。我们也将模型与原始 Accel-Sim 进行对比，因为新模型基于其构建。

我们选取了来自 12 个基准套件的广泛基准。各套件、应用数量与输入集数量见 表 3。总计 143 个基准，其中 83 个为不同应用，其余为同应用不同输入。

性能准确性

表 4 展示了我们模型与 Accel-Sim 相对于真实硬件的 MAPE。可以看到，我们模型在所有 GPU 上都更准确，且对最大规模的 NVIDIA RTX A6000，MAPE 不到 Accel-Sim 的一半。相关系数方面，两者接近，但我们略优。

图 5 展示了 RTX A6000 上两种模型的 APE 分布（基准按误差排序）。我们模型在所有应用上 APE 更低，并且对约半数应用差距显著。Accel-Sim 在 10 个应用上 APE 大于等于 100%，最坏达到 543%，而我们的模型 APE 从未超过 62%。以 90 分位为衡量尾部准确性，Accel-Sim 为 82.64%，而我们为 31.47%。这表明我们的模型明显更准确且更稳健。

指令预取的敏感性分析

流缓冲指令预取器的参数对模型准确性影响很大。我们评估了多种配置：关闭预取、完美指令缓存，以及流缓冲大小为 1、2、4、8、16、32 的配置，均基于 RTX A6000。结果见 表 5，可见最佳准确性对应流缓冲大小为 16。

从 表 5 的加速结果还可得出一条结论：简单的流缓冲预取器在 GPU 上的行为接近完美指令缓存。这是因为 sub-core 中的不同 warp 往往执行同一代码区域，而典型 GPGPU 应用控制流较简单，预取连续 行通常有效。由于 GPU 不进行分支预测，采用 Fetch-Directed 预取[69] 不划算。

就仿真准确性而言，当不研究指令缓存增强时，完美指令缓存通常能以更高速度提供近似准确性。但对控制流较复杂的基准（如 Rodinia 的 dwt2d、lud、nw），完美指令缓存或不使用流缓冲会导致显著不准确（相对完美 ICache 误差超过 20%，相对无预取甚至超过 200%）。这是因为完美 ICache 无法体现频繁跳转带来的性能惩罚，而无预取则过度惩罚程序的其他部分，这也表明这些基准仍有改进空间。

寄存器文件架构的敏感性分析

表 6 展示了寄存器文件缓存（RFC）与每 bank 读端口数量对准确性与性能的影响，并给出了理想配置（所有操作数可在一个周期取回）。总体平均性能与准确性在各配置间相近，但特定基准表现更微妙：例如计算密集型的 MaxFlops（Accel-Sim GPU Microbenchmark）与使用 sgemm 参数的 Cutlass[13], [60]。这两者高度依赖固定延迟算术指令，而这类指令通常有 3 个操作数，易受寄存器文件访问限制影响。

对 MaxFlops 而言，RFC 是否存在对性能影响不大，因为仅有一条静态指令使用 RFC。但当每 bank 读端口数增至 2（总共 4 个读端口）时，性能提升约 44%，因为每条指令常有 3 个操作数。相对地，从仿真准确性角度看，2 端口配置偏差明显。

对 Cutlass（sgemm）而言，单端口且无 RFC 会导致性能显著下降（0.78x），与程序中约 35.9% 的静态指令至少有一个操作数使用 RFC 的观察一致。引入每 bank 2 个读端口则提升约 12% 性能，说明寄存器文件与缓存结构仍有优化空间。

总之，寄存器文件架构及其缓存对个别基准影响显著，准确建模十分关键。平均而言，单端口 + 简单缓存已接近“无限端口”效果，但对某些基准差距仍很大，值得进一步研究。

依赖管理机制分析

本小节比较本文揭示的软硬协同依赖管理机制与传统记分牌方法在性能与面积上的影响。表 7 给出结果。面积开销相对于一个 SM 的常规寄存器文件（256 KB）。

传统记分牌机制需要为所有可写寄存器提供条目，即每 warp 332 个条目（255 常规寄存器、63 统一寄存器、7 谓词寄存器、7 统一谓词寄存器）。此外需两个记分牌：一个处理 RAW/WAW，另一个处理 WAR[17]，因为虽然发射顺序严格，但可变延迟指令的读写可能乱序，导致 WAR。WAR 记分牌需要记录每条目消费者数量。若支持最多 63 个消费者，则单 warp 需要 2324 bit（）。按 48 个 warp 的 SM 计算，总计 111,552 bit，占寄存器文件面积的 5.32%。

相比之下，本文的软硬协同机制仅需每 warp 6 个 6-bit 依赖计数器、4-bit 停顿计数器与 1-bit Yield，共 41 bit。每个 SM 仅 1968 bit，占寄存器文件面积的 0.09%，远小于记分牌方案。

综上，基于控制位的软硬协同机制在性能与面积上优于其他方案，且面积开销极小。在支持 64 个 warp/SM 的架构（如 Hopper[22]）中，对比更显著：控制位方案开销为 0.13%，而记分牌方案（63 消费者）为 7.09%。此外，在无法获取控制位的应用场景（如部分 Deepbench 内核）中，使用双记分牌（RAW/WAW 与 WAR）且最大消费者 63 的方案在仿真准确性上与控制位接近，因此是有效替代方案。

向其他 NVIDIA 架构的可移植性

本文主要聚焦 Ampere，但结论同样适用于 Turing 等架构。除四种 Ampere GPU 的结果外，表 4 还给出 Turing GPU 结果，显示对 NVIDIA RTX 2080 Ti 的 MAPE 相比 Accel-Sim 提升 6.94%。

虽然我们仅在 Turing 与 Ampere 上验证了模型，但认为其结论可适用于更广泛的 NVIDIA 架构。公开资料与 SM 结构图显示，近期架构的重大变化主要集中在张量核心、光线追踪单元，以及如 TPC 内 SM 之间共享内存的分布式特性等小幅改动[22]。不过，为适配其他架构仍需重新估计部分指令（如内存指令）的延迟。

TableGen

TableGen是描述体系结构（包括寄存器，指令集，调用约定等）的专用编程语言， 其目标是创建可维护、易于阅读的代码来描述体系结构。 在构建LLVM时，TableGen工具将TableGen代码翻译为C++并将其与手工编码的C++文件一起编译。

注意：实际上，我发现TableGen代码很难阅读，更难编码！

简而言之，TableGen是具有以下功能的声明性编程语言：

• 有两个主要组件： record和class。 record是class的实例，包含了名称和相关字段的值。 class是record的抽象，可用于生成具体的record。 两者相互配合可以很好地提取公共代码并减少重复。

• record可以从一个或多个class继承，还可以定义自己的字段。

• 字段具有名称和值（或值列表），值具有特定的类型（如bit或int）。这是类型列表。

• include指令用于将TableGen代码从一个文件包含到另一个文件中，就像C的#include一样。

以下是从LLVM文档中获取的示例，其中显示了一个非常简单的TableGen文件。 它包含一个classC，该class定义了值为1的bit类型的字段V， 还声明了一个从类C派生的记录X。

class C {
  bit V = 1;
}
def X : C;

后端需要定义TableGen的record，用以声明指令、寄存器等。 这些record必须从内部类继承，这样TableGen工具才能魔术地为这些record生成适当的C++代码。 例如，声明寄存器的record必须从内部的Register类继承。 在这篇文章中，我们将查看声明寄存器和指令的TableGen代码。

注意:TableGen文档在解释它是什么和语法方面做得很好。 但是，介绍后端应该重用的内部类和预定义记录的文档却很少；要了解这些内容您必须查看源代码。

注意:回想一下之前的文章， 我们的CMake文件使用带各种参数的TableGen命令把扩展名为.td的TableGen代码文件转化为扩展名为.inc的C++文件。 在构建系统发出TableGen命令之后，可以在build/lib/Target/RISCW的构建目录中找到生成的文件。 Tablegen的参数可以这里(非常简短地)查看。

注意:TableGen还可以配置指令选择过程中的调度和形成阶段，但是我不会在本教程中讨论这一点。 如果你感兴趣，可以看看这个视频。

定义寄存器

RISCW的寄存器定义非常简单， 可以在llvm/lib/Target/RISCW/RISCWRegisterInfo.td中找到。 让我们对其进行剖析，以了解TableGen的工作方式。

在文件的顶部，我们找到以下类。

let Namespace = "RISCW" in {
class RISCWReg<bits<5> Enc, string n, list<string> alt = []> : Register<n> {
  let HWEncoding{4-0} = Enc;
  let AltNames = alt;
}
} // end Namespace

该代码声明了一个RISCWReg类，该类继承自在include/llvm/Target/Target.td中定义的内部类Register。 该代码还告诉我们，从此类继承时，我们必须提供最多三个参数：

• 寄存器编码Enc，它是类型为bits<5>的5位整数。

• 字符串n，表示人类可读的寄存器名称，如RISCV中的x0、x1等。

• 寄存器的别名列表，该列表是可选的。 例如，RISCV中的x2也可以称为sp，即堆栈指针。 但请注意，此列表是可选的，因为可以声明没有别名的寄存器，如果寄存器没有别名，则把alt设置[]。

另外，请注意Register类接受一个参数：类型为字符串的寄存器名称。 RISCWReg的其余两个参数（Enc和alt）被let语句用于覆盖Register类定义的HWEncoding和AltNames域。 您可以在这里和这里阅读Register的代码。

接下来，我们在该文件中找到以下Register定义。 每一行代码都是一个record，它定义了一个寄存器。 这些record继承自两个类:RISCWReg(我们已经讨论过了)和DwarfRegNum。 DwarfRegNum是这里定义的另一个内部类，用于为GCC和GDB提供调试信息。

def X0  : RISCWReg<0, "x0", ["zero"]>, DwarfRegNum<[0]>;
...
def X31 : RISCWReg<31,"x31", ["t6"]>, DwarfRegNum<[31]>;

文件的最后几行定义寄存器组， RISCW定义了两种寄存器组：GPR通用寄存器和堆栈指针SP寄存器。

def GPR : RegisterClass<"RISCW", [i32], 32, (add
    (sequence "X%u", 10, 17),
    (sequence "X%u", 5, 7),
    (sequence "X%u", 28, 31),
    (sequence "X%u", 8, 9),
    (sequence "X%u", 18, 27),
    (sequence "X%u", 0, 4)
  )>;

def SP : RegisterClass<"RISCW", [i32], 32, (add X2)>;

定义Register组的record继承自RegisterClass类，后者具有四个参数（还有一个可选的第五个参数，我们将不讨论）：

• 命名空间在我们的例子中是RISCW，这与我们在上面的RISCWReg类中重写的名称空间字段相匹配。

• 此组寄存器支持的数据类型列表。 这是一个列表，因为某些体系结构中的寄存器可以支持多种数据类型。 例如，一些64位计算机的寄存器可以在32位和64位模式下工作。 RISCW只适用于32位机器，因此寄存器总是32位，它们的类型就是i32。

• 从内存中存储或加载寄存器时寄存器的对齐方式。

• 一个DAG，指示此寄存器组包含的寄存器。还有…

  • 我是说DAG！注意，GPR的DAG有一个ADD模式，该模式有6个sequence节点。 sequence是一种操作，它接受字符串格式参数以及起始值和结束值。 序列中的每个元素都是TableGen工具根据格式参数指定的格式生成。 所以，这个DAG的另一种写法是(add X10, X17,…, X3, X4)。

  • 此DAG还指定了寄存器分配器使用寄存器的顺序。 例如，如果两者都可用，分配器将优先使用来自GPR的x10而不是x4。

寄存器组稍后用于配置合法化器。

定义指令

计算机体系结构使用一组格式对指令进行编码。 例如，RISCV体系结构使用32位编码和4种基本指令格式来编码指令³。 此外，每种格式都有一组唯一的操作码(或操作码)。 然后使用格式和操作码对特定指令进行编码，这使处理器能够识别指令并确定它们的操作数。

在LLVM中，定义指令的方式与定义指令集编码的方式类似。 定义指令的代码通常由两部分组成: 格式定义和指令定义。

class InstFormat<bits<5> val> {
  bits<5> Value = val;
}
def InstFormatPseudo : InstFormat<0>;
def InstFormatR      : InstFormat<1>;
...
def InstFormatOther  : InstFormat<17>;

class RISCWOpcode<bits<7> val> {
  bits<7> Value = val;
}
def OPC_LOAD      : RISCWOpcode<0b0000011>;
def OPC_LOAD_FP   : RISCWOpcode<0b0000111>;
...
def OPC_SYSTEM    : RISCWOpcode<0b1110011>;

class RWInst<dag outs, dag ins, string opcodestr, string argstr,
             list<dag> pattern, InstFormat format>
    : Instruction {
  field bits<32> Inst;
  field bits<32> SoftFail = 0;
  let Size = 4;
  ...
  let TSFlags{4-0} = format.Value;
}

class Pseudo<dag outs, dag ins, list<dag> pattern, string opcodestr = "",
             string argstr = "">
    : RWInst<outs, ins, opcodestr, argstr, pattern, InstFormatPseudo>,
      Sched<[]> {
  let isPseudo = 1;
  let isCodeGenOnly = 1;
}

class RWInstR<bits<7> funct7, bits<3> funct3, RISCWOpcode opcode, dag outs,
              dag ins, string opcodestr, string argstr>
    : RWInst<outs, ins, opcodestr, argstr, [], InstFormatR> {
  bits<5> rs2;
  bits<5> rs1;
  bits<5> rd;

  let Inst{31-25} = funct7;
  ...
  let Opcode = opcode.Value;
}
...

let hasSideEffects = 0, mayLoad = 0, mayStore = 0 in
class ALU_rr<bits<7> funct7, bits<3> funct3, string opcodestr>
    : RWInstR<funct7, funct3, OPC_OP, (outs GPR:$rd), (ins GPR:$rs1, GPR:$rs2),
              opcodestr, "$rd, $rs1, $rs2">;

def ADD : ALU_rr<0b0000000, 0b000, "add">, Sched<[WriteIALU, ReadIALU, ReadIALU]>;

let hasSideEffects = 0, mayLoad = 0, mayStore = 0 in
def ADD : RWInstR<0b0000000, 0b000, OPC_OP, (outs GPR:$rd),
              (ins GPR:$rs1, GPR:$rs2), "add", "$rd, $rs1, $rs2">,
          Sched<[WriteIALU, ReadIALU, ReadIALU]>;

def simm12 : Operand<i32>, ImmLeaf<i32, [{return isInt<12>(Imm);}]> {
  let ParserMatchClass = SImmAsmOperand<12>;
  let EncoderMethod = "getImmOpValue";
  let DecoderMethod = "decodeSImmOperand<12>";
  let MCOperandPredicate = [{
    int64_t Imm;
    if (MCOp.evaluateAsConstantImm(Imm))
      return isInt<12>(Imm);
    return MCOp.isBareSymbolRef();
  }];
  let OperandType = "OPERAND_SIMM12";
  let OperandNamespace = "RISCWOp";
}

...

let hasSideEffects = 0, mayLoad = 0, mayStore = 0 in
class ALU_ri<bits<3> funct3, string opcodestr>
    : RWInstI<funct3, OPC_OP_IMM, (outs GPR:$rd), (ins GPR:$rs1, simm12:$imm12)
              opcodestr, "$rd, $rs1, $imm12">,
      Sched<[WriteIALU, ReadIALU]>;

合法化

类型和操作的合法化阶段均在后端的TargetLowering子类中使用C++代码进行配置。 在RISCW中，此类为RISCWTargetLowering，其代码在lib/Target/RISCW/RISCWISelLowering.cpp和lib/Target/RISCW/RISCWISelLowering.h中。 我们为支持算术指令所做的大多数更改实际上都在构造函数中。

RISCWTargetLowering::RISCWTargetLowering(const TargetMachine &TM,
                                         const RISCWSubtarget &STI)
    : TargetLowering(TM), Subtarget(STI)
{
  addRegisterClass(MVT::i32, &RISCW::GPRRegClass);
  ...

  setSchedulingPreference(Sched::RegPressure);
  ...

  setOperationAction(ISD::SRA_PARTS, MVT::i32, Custom);
  ...

  setOperationAction(ISD::ROTL,  MVT::i32, Expand);
  ...
}

有几件事值得注意：

• addRegisterClass用于配置LLVM寄存器组和对应的寄存器类型，此信息用于类型合法化。

• setSchedulingPreference用于配置调度和形成阶段。这里我们告诉LLVM使用一个最小化寄存器压力的算法。

• setOperationAction用于配置LLVM如何使操作合法化，即合法化Section DAG中的节点。 回想一下，有三个选项：扩展、提升和自定义。 LLVM会自动处理前两个操作， 例如，RISCV没有位旋转指令，因此我们要求编译器将该操作扩展为其他操作，如移位和ors以模拟旋转。 标记为自定义的操作在TargetLowering子类中由C++代码处理。

每当LLVM在合法化过程中遇到具有custom操作的DAG节点时， 都会生成对TargetLoweing类的LowerOperation方法的回调。 例如，SHL_PARTS操作用于将64位整数左移。 我们通过构造函数中的setOperationAction(ISD:：SHL_PARTS，MVT:：i32，Custom)来告诉LLVM， 我们实现了一个LowerShlParts函数来来合法化此操作。 LowerShlParts用32位移位和ors等其他合法操作来代替SHL_PARTS节点。 我鼓励您看看代码，看看这是如何工作的！

注意：需要合法化的操作完全取决于后端实现的指令集， 以及TableGen代码中DAG节点与指令匹配的程度（下一节将对此进行详细介绍！）。 如果使某些操作合法化太复杂或发出的代码效率低下， 则说明您的指令集可能缺少某些指令！

目标指令选择

目标指令选择阶段将后端TableGen文件中提供的DAG模式匹配到Section DAG中的节点。 匹配成功时，Section DAG中的节点将被替换为具体机器(或伪)指令的节点。 因此，TableGen定义的模式的质量对于发出好的代码至关重要， 您应该多花费些时间来调整这些模式!

注意：TableGen模式通常定义在llvm/lib/Target/<BACKEND>/<BACKEND>InstrInfo.td文件的末尾。

模式records继承自LLVM的Pat类， 该类有两个参数， 第一个参数是一个包含要匹配的模式DAG，第二个参数是一个带有机器指令的DAG。 当模式匹配DAG中的某个内容时，匹配的节点被第二个参数中的DAG替换。

不出所料，我们将使用一些类来帮助我们简化模式的定义。 这里有两个这样的类：

class PatGprGpr<SDPatternOperator OpNode, RWInst Inst>
    : Pat<(OpNode GPR:$rs1, GPR:$rs2), (Inst GPR:$rs1, GPR:$rs2)>;
class PatGprSimm12<SDPatternOperator OpNode, RWInstI Inst>
    : Pat<(OpNode GPR:$rs1, simm12:$imm12), (Inst GPR:$rs1, simm12:$imm12)>;

PatGprGpr用带有两个通用寄存器操作数作为输入的指令替换DAG中的节点。 例如，下面是ADD指令的模式声明:

def : PatGprGpr<add, ADD>;

PatGprSimm12将DAG中的节点替换为具有一个通用输入操作数和一个12位立即数的指令。 为了实现这一点，用simm12取代了Pat中第一个和第二个参数中的GPR。 回想一下，simm12是我们在本文前一节中讨论过的一个record。 它继承自Operand类，因此可以在指令的定义中使用。 simm12也继承自ImmLeaf类，因此也可以在模式定义中使用。 下面是ADDI指令的定义，该指令接受一个立即数:

def : PatGprSimm12<add, ADDI>;

注意：ImmLeaf类是用于匹配立即数的模式。 它的参数是即时类型，例如I32、I16以及谓词等。 谓词即C++代码块， 它检查指定模式必须满足的条件。 例如，simm12有一个谓词return isInt<12>(Imm)来检查整数是否在12位范围内。

注意：有时，同一条指令可以与Selection DAG中的多个模式匹配。 在这种情况下，使用LLVM的PatFrag类和Pat来避免代码重复， 如RISCW的bit-shift模式。

注意:RISCW和RISCV后端首先声明指令， 并分别提供模式record。 然而，其他后端，如ARM或XCore，以不同的方式创建Instruction的子类，以便它们接受一个模式参数。 这种方法减少了代码行数，因为模式可以在定义指令的同一record中提供， 但在我看来，这使得TableGen代码更难阅读(也更难解释!)

当在DAG中找到匹配时， Pat的第二个参数也可以转换操作数(通常是立即数)。 为此，我们首先需要声明一个继承自SDNodeXForm的操作节点。 SDNodeXForm以实现所需转换的一段c++代码作为参数。 然后，我们在模式中使用新声明的节点，如下面的示例所示。 在本例中，HI20节点提取立即数的20个最重要的比特位。

def HI20 : SDNodeXForm<imm, [{
  return CurDAG->getTargetConstant(((N->getZExtValue()+0x800) >> 12) & 0xfffff,
                                   SDLoc(N), N->getValueType(0));
}]>;

def : Pat<(simm32hi20:$imm), (LUI (HI20 imm:$imm))>;

注意：SDNodeXForm节点不插入实际指令。 它们通常用于转换即时数据，因此可以在代码发出之前就完全解析。

随着指令选择的进行，LLVM每个Selection DAG节点调用SelectionDAGISel子类的Select方法。 因此，后端可以在Select方法中提供代码， 实现复杂的模式匹配， 而这种匹配在TableGen中很难表达。 例如，RISCW的Select方法包括用x0寄存器来替换常量0的代码。

注意:SelectionDAGISel子类通常在文件llvm/lib/Target/<backend>/<backend>ISelDAGToDAG.h和llvm/lib/Target/<backend>/<backend>ISelDAGToDAG.cpp中。 例如，RISCW后端相关代码在llvm/lib/Target/RISCW/RISCWISelDAGToDAG.h和llvm/lib/Target/RISCW/RISCWISelDAGToDAG.cpp中。

构建DAG

这是指令选择的第一阶段。 它接受LLVM IR作为输入， 并产生Selection DAG(有向无环图)作为输出。 指令选择过程中的每个其他阶段都在DAG上执行，直到产生输出指令序列。 正如前面几篇文章所讨论的，LLVM IR是前端工具(如Clang)根据C代码生成，随后由LLVM优化器进行优化。 下面是C程序的LLVM IR:

define dso_local i32 @MUL(i64 %x, i32 %y) local_unnamed_addr #0 {
entry:
  %0 = trunc i64 %x to i32
  %conv1 = mul i32 %0, %y
  ret i32 %conv1
}

Selection DAG实际上是一种精巧的树型数据结构，它表示LLVM IR中的基本块。 基本块是不包含分支目的地（入口除外）和分支指令（出口除外）的指令序列。 示例MUL函数非常简单，它只有一个称为入口的基本块，其他函数通常具有多个基本块。 例如，下面的hello函数具有四个基本块：entry，if.then，if.else和return。 每个基本块都将被转换为单独的DAG。

define dso_local i32 @hello(i32 %x) local_unnamed_addr #0 {
entry:
  %cmp = icmp eq i32 %x, 100
  br i1 %cmp, label %if.then, label %if.else

if.then:                                          ; preds = %entry
  %call = tail call i32 bitcast (i32 (...)* @hello100 to i32 (i32)*)(i32 100) #2
  br label %return

if.else:                                          ; preds = %entry
  %call1 = tail call i32 bitcast (i32 (...)* @helloOther to i32 (i32)*)(i32 %x) #2
  br label %return

return:                                           ; preds = %if.else, %if.then
  %retval.0 = phi i32 [ %call, %if.then ], [ %call1, %if.else ]
  ret i32 %retval.0
}

Selection DAG具有以下属性： + 每个节点都是SDNode类的实例，代表一个操作，如加、减、乘等。 操作类型都定义在文件include/llvm/CodeGen/ISDOpcodes.h中。 + 每个节点都有0个或多个操作数，操作数由其他节点定义，用指向该节点的边表示，边是SDValue类的实例。 + 操作产生的值的类型为MTV（Machine Value Type），比如i1和i8，它们分别表示1位和8位整数。 + 具有副作用的节点会强制对操作进行排序，例如return和loads语句，它们具有类型为MVT::Other的特殊chain值， 既作为输入操作数又作为输出操作数。 + ISD::EntryToken类型的叶节点是代码的入口。 + DAG的根节点是带有链操作数的最终副作用节点。这是的代码块的最后一个操作，例如函数结尾处的返回。

警告！LLVM后端的类型系统非常有限。 当输入的LLVM IR被转换为DAG时，许多有用的类型信息被丢弃。 最值得注意的丢弃是指针类型，MVT类的类型列表完全没有包含指针类型。 因此，指针在DAG中使用整数类型表示，所以很难判断一个节点(如add)的操作数是指针还是整数。

这是我从MUL函数获得的初始Selection DAG。

入口节点位于图的顶部，而根节点位于底部。 还有一个由蓝色边连接的节点链，从根节点开始，到入口节点结束。 这些蓝边就是前面讨论过的链操作数。 黑色边显示的是值的流动，如整数和浮点数。 此Selection DAG的等效文本表示如下所示：

t0: ch = EntryToken
        t2: i32,ch = CopyFromReg t0, Register:i32 %0
        t4: i32,ch = CopyFromReg t0, Register:i32 %1
      t7: i64 = build_pair t2, t4
    t8: i32 = truncate t7
    t6: i32,ch = CopyFromReg t0, Register:i32 %2
  t9: i32 = mul t8, t6
t11: ch,glue = CopyToReg t0, Register:i32 $x0, t9
t12: ch = RISCWISD::Ret t11, Register:i32 $x0, t11:1

注意：Selection DAG可以同时包含目标独立和目标相关的节点。 目标独立的操作定义在文件ISDOpcodes.h中。 目标相关的操作由每个后端定义，通常定义在声明TargetLowering子类的同一文件中。 您可以在llvm/lib/Target/RISCW/RISCWISelLowering.h中找到目标相关节点的定义。 上面显示的用于MUL的Selection DAG具有节点t12，该节点代表目标相关操作RISCWISD::Ret，该函数表示从函数返回。

注意：在指令选择过程的各个阶段，您可以通过向llc命令传递-view-dag-combine1-dags，-view-legalize-dags，-view-dag-combine2-dags参数告诉LLVM生成Selection DAG的可视化表示，还可以通过向llc命令传递-debug参数告诉LLVM生成Selection DAG的文本表示。

优化

指令选择阶段会有三次DAG优化过程，第一次优化发生在LLVM IR构建Selection DAG之后。 其余两次将在合法化阶段后执行。 根据LLVM文档，这些优化旨在简化可能由其他阶段(如合法化)生成的不必要的复杂Selection DAGs。

就我所知，LLVM的优化过程就是通过运行一个编译pass将一组节点组合成更简洁的节点。 为了实现这一点，LLVM用这个巨大的C++文件(>20,000行)遍历DAG，并通过模式匹配来寻找优化机会。 例如，合并器可以将Selection DAG的(add (add x, y) z)节点，转换为(add x，y + z)节点，从而消除了add节点。

下图显示了MUL示例函数第一遍优化后的Selection DAG。 与上一节中的Selection DAG相比，优化的DAG用节点t13代替了节点t3和t4。 该优化将丢弃64位整数x的高32位，因为函数MUL的返回值仅依赖x的低32位， 因此，可以通过消除t3和t4简化DAG。

LLVM的DAG合成器只优化目标独立的操作，即ISDOpcodes.h中定义的add、sub、load、store等。 通过覆盖targetlower子类中的PerformDAGCombine函数， 后端可以为合成器提供额外的优化功能，这些功能可以是目标独立的也可以是目标依赖的。 此外，后端必须通知优化器受支持的目标独立的节点， 这通过在targetlower类的子类的构造函数中调用setTargetDAGCombine函数完成。

注意：令人困惑的是，LLVM后端的TargetLowering子类通常在<TARGET_NAME>ISelLowering.cpp文件中实现。 您可以在llvm/lib/Target/RISCW/RISCWISelLowering.cpp中找到RISCW的实现。

注意：XCore后端有一个很好的PerformDAGCombine和setTargetDAGCombine例子（参见这里和这里） ——我的意思是很容易阅读。 另外，看看这个后端是如何将add(add(mul(x，y)，a)，b)节点组合到更简单的目标依赖的lmul(x，y，a，b)节点， 因为XCore架构有一个乘法累加指令³。

类型和操作合法化

上面显示的优化的DAG包含一个节点t7， 它会产生一个i64类型的值， 但是RISCW机器只支持32位。 合法化阶段会解决这些问题。

首先执行的是类型合法化， 它将DAG转换为仅使用本地计算机原生支持的数据类型。 为了实现这一点，它将小类型转换或提升为较大的类型； 例如，i1类型的1位整数转换为i32类型的32位整数。 此外，编译器将大整数分解或展开为较小的整数，例如在32位计算机中，i64类型的64位整数被转换为i32类型的32位整数。 下面的DAG是前面展示的DAG的合法化版本。 在本例中，编译器消除了t3和t7节点，以确保新的DAG只使用i32整数。

操作合法化在第二个优化阶段之后执行。 它将DAG转换为仅使用本地计算机原生支持的操作。 例如，DAG可能包含bit-rotate left（rotl）节点，但目标指令集可能不支持该指令， 因此，操作合法化把该操作转化为移位和或运算的联合操作。

有三种使操作合法化的策略。 首先，将不受支持的操作扩展为一组受支持的操作来模拟原不受支持的操作。 其次，把类型提升为更大的类型，以支持缺失的操作。 第三，使用TargetLowering类的子类中的钩子在C++中实现自定义的合法化。

注意：在以后的文章中，我将解释后端如何配置合法化阶段。 这可以在TargetLowering类的子类的构造函数中完成。

指令选择

此时，DAG包含大部分目标独立（如加和减）节点，以及一小部分目标依赖节点（如RISCWISD::Ret）。 下一步，需要将这些抽象操作映射到目标架构的具体机器指令， LLVM在指令选择阶段会对此进行处理。 处理方法很简单：编译器通过模式匹配将DAG中的节点映射成机器指令。 指令的模式和描述由编译器后端的开发人员通过TableGen代码提供。 另外，可以使用C++直接编写难以使用TableGen描述的复杂模式。

我们将在以后的文章中更仔细地研究TableGen。 现在，让我们考虑一下LLVM如何将合法且优化的DAG映射成下面显示的新DAG。 在这种情况下，只有两个节点需要更改。 t9用指令MUL替换了mul操作，而t12用指令PseudoRet替换了RISCWISD::Ret。

调度和形成

谢天谢地，这里没什么好说的，因为帖子已经很长了！ 此阶段根据某些约束将DAG转换为指令列表。 例如，后端可以通过TargetLowering子类的构造函数调用setSchedulingPreference来指定调度选项。

警告！ 一定要尝试不同的调度首选项！ 如果调度策略与体系结构和处理器的特性不匹配，那么调度策略会显著降低所发出的代码的质量。 这里列出了各种调度选项。

下面是我们MUL函数的指令清单。 有几个重要的事情要注意。 首先，与实际机器的寄存器相反，生成的代码仍然使用一组无限多的虚拟寄存器； 编译器稍后会通过寄存器分配器来处理这个问题。 第二，已经存在一些对寄存器分配过程有用的生命周期信息；例如，有两个寄存器，即x0和x2， 它们在基本块的开始处就处于活动状态。

bb.0.entry:
  liveins: $x0, $x2
  %2:gpr = COPY $x2
  %0:gpr = COPY $x0
  %3:gpr = MUL %0:gpr, %2:gpr
  $x0 = COPY %3:gpr
  PseudoRET implicit $x0

CMake配置文件

回想一下，RISCW后端存放在llvm/lib/Target/RISCW目录下。 该目录及其子目录都有两个构建文件(CMakeLists.txt和LLVMBuild.txt)，描述后端模块的结构，提供链接信息等。 RISCW后端目前非常简单，目录结构是这样的:

llvm/lib/Target/RISCW
|- CMakeLists.txt
|- LLVMBuild.txt
|- Other C++, TableGen, etc files
|- TargetInfo/
|  |- CMakeLists.txt
|  |- LLVMBuild.txt
|  |- Other C++, TableGen, etc files
|- MCTargetDesc/
   |- CMakeLists.txt
   |- LLVMBuild.txt
   |- Other C++, TableGen, etc files

每个使用CMake的项目都会包含CMakeLists.txt文件³，RISCW也不例外。 这些文件包含一系列CMake指令，这些指令用于驱动构建文件的生成。 在LLVM后端中，CMake会根据这些指令执行一些操作，例如指示要编译的C++源文件或生成TableGen指令。 LLVMBuild.txt文件对当前目录中包含的组件提供了描述。

LLVMBuild.txt文件

让我们看一下llvm/lib/Target/RISCW/LLVMBuild.txt的内容。

[common]
subdirectories = MCTargetDesc TargetInfo

[component_0]
type = TargetGroup
name = RISCW
parent = Target
has_asmprinter = 1

[component_1]
type = Library
name = RISCWCodeGen
parent = RISCW
required_libraries = AsmPrinter CodeGen Core MC RISCWDesc RISCWInfo
  SelectionDAG Support Target

add_to_library_groups = RISCW

该文件告诉构建系统RISCW后端具有两个组件。 其中一个是顶级组件RISCW，其类型为TargetGroup，该类型表明RISCW是一个后端，构建系统对该类型有一些特殊处理。 Target是RISCW的父组件。 请注意，此命名与LLVM后端的目录结构匹配，即llvm/lib/Target/RISCW。 RISCW的名称也不是任意的，它必须与后端的TableGen文件中的定义匹配。

LLVM后端提供了一系列可选功能， 例如assembly printing，assembly parsing等， LLVMBuild.txt文件表明了后端支持哪些可选功能。 比如，最后一行告诉构建系统RISCW后端实现了assembly printing功能。

注意：查看现有后端（如ARM或RISCV）中的代码，以了解它们除了has_asmprinter之外还启用了哪些功能。

LLVMBuild.txt文件还定义了第二个名为RISCWCodeGen的组件，其类型为Library，其父级为RISCW。 另外，文件还指明了RISCWCodeGen需要的依赖库，例如AsmPrinter，CodeGen等，构建LLVM时，缺少库会导致链接错误。

llvm/lib/Target/RISCW的每个子目录也会包含一个LLVMBuild.txt文件，该文件使用RISCW作为父级来定义自己的组件。

CMakeLists.txt文件

让我们看一下llvm/lib/Target/RISCW/CMakeLists.txt文件的内容。

set(LLVM_TARGET_DEFINITIONS RISCW.td)

tablegen(LLVM RISCWGenRegisterInfo.inc -gen-register-info)
tablegen(LLVM RISCWGenInstrInfo.inc -gen-instr-info)
# Other TableGen commands

add_public_tablegen_target(RISCWCommonTableGen)

# RISCWCodeGen should match with LLVMBuild.txt RISCWCodeGen
add_llvm_target(RISCWCodeGen
  RISCWAsmPrinter.cpp
  # Other files
)

# Should match with "subdirectories =  MCTargetDesc TargetInfo" in LLVMBuild.txt
add_subdirectory(TargetInfo)
add_subdirectory(MCTargetDesc)

文件顶部的set命令将LLVM_TARGET_DEFINITION定义为`RISCW.td**。 这个文件通常包含一些顶级定义， 并通过包含其他文件的方式来引入其他TableGen定义——我们将在后面的文章中更仔细地研究TableGen， 但是请随时查看代码库中的RISCW.td。

然后我们在CMake文件中看到一些TableGen命令。 它们命令构建系统使TableGen工具根据*.td文件生成RISCWGen*.inc。 这些*.inc文件实际上就是传统的C++代码，在编译完LLVM之后，你可以在build/lib/Target/RISCW的构建目录中找到它们；它们可以用于调试，但是不容易阅读。

接下来的命令，也就是add_llvm_target， 指定了当前目录中要构建的C++文件，被指定的文件不能位于子目录中。 add_llvm_target命令的第一个参数是目标的名称，并且应该与LLVMBuild.txt中定义名称匹配。

最后，CMakeLists.txt指定了CMake应该查看的子目录，在后端RISCW中，只有两个:TargetInfo和MCTargetDesc。 子目录中的CMakeLists.txt与此类似，但要简单得多!

注意:后端文件的命名约定通常很重要，显然应该与构建文件的内容相匹配。 例如，set(LLVM_TARGET_DEFINITIONS RISCW.td)命令要求RISCW.td存在! 一定要仔细检查这些错误，因为构建错误可能有点含糊不清。

Triple和ELF配置

我们首先为后端配置一个新的目标描述Triple。 由于历史原因，Triple编码了目标平台的重要信息（如体系结构、供应商和操作系统）。 以下是配置一个新的Triple的步骤:

1. 在llvm/include/llvm/ADT/Triple.h用Triple声明一个新的体系结构 (见这里)。
2. 提供字符串和Triple之间的类型转换(参见这里,这里及这里)。
3. 指出后端支持的目标文件类型，例如ELF、COFF等，ricw只支持ELF(参见这里)。
4. 指出目标平台的字平台，例如32位或64位，以及指针的大小(请参阅这里,这里及这里)。

注意:你可以在这里和这里找到更多关于Triple的信息。

注意:指令集并不一定意味着指针的大小。 例如，在为RV64编译时，指针并不总是64位的。 指针大小通常由ABI给出，在64位机器中，它可以是ilp32(即int、long和指针为32位)。

下面的参数用于配置ELF:

1. 创建一个枚举值作为RISCW的体系结构的标识(见此处)。 这个值被编码在ELF文件头的e_machine字段中。 这个值不是随意设置的; 它必须取得授权，例如:0xF3 for RISCV。 但是我们现在将它设置为一个未使用的值。

2. 声明ELF重定位类型(见这里和这里)。 同样，这些是依赖于架构的，这里列出了用于RISCV的类型。 在这个阶段，我们将简单地为RISCW放置了占位符。

3. 文件格式名称(见此处)。

4. 指示给定类的目标描述Triple(见此处)。目前，ELF头中的类是一个字节，用于对格式是32位还是64位进行编码。

注意:查看wikipedia获取更多关于ELF文件的信息。

配置驱动器

回想一下，我们使用clang将输入的C代码编译成LLVM IR。 但是clang不仅仅是我们的编译器前端，它也是一个驱动器，类似GCC，驱动编译流水线将输入的C程序转换为另一个表示，比如把C转换为汇编或目标代码。 因此，我们需要告诉clang

1. 新后端的支持特性。例如，clang需要知道RISCW是32位还是64位。

2. 新后端的编译流程。例如，它应该使用什么汇编程序? 什么连接器? 有哪些包括路径等等。

我们可以通过添加一个新的target类RISCWTargetInfo来告诉clang有关RISCW的信息，该类与LLVM已有的target类一起被实例化，如这里所示。 该类在这里和这里分别被声明和定义。 在这段代码中有一些重要的事情需要强调:

• RISCWTargetInfo通过字符串描述数据布局。这个字符串编码许多重要信息，比如指针中每一位、堆栈对齐要求等。
• 基本C数据类型的大小。
• 函数RISCWTargetInfo::getTargetDefines(**指示编译时定义的C预处理器宏，例如，这些宏是在使用RISCV后端编译代码时定义的。 宏通常描述后端支持的体系结构、ABI、启用/禁用任何特性等

注意:一个后端可能支持多个指令集和ABI，因此驱动器的配置必须根据选定的目标Triple进行更改。 例如，RISCWTargetInfo根据Triple包含riscv32还是riscv64来更改数据布局字符串。

注意:这里可以查看RISCWTargetInfo的父类TargetInfo的声明。 它包含了更多的可以配置的选项。

配置工具链相对简单。 我们只需要实现一个从Toolchain继承的RISCWToolChain类，如下所示。 代码基本上是不言自明的，通过覆盖ToolChain类的成员，您可以修改更多的选项(见此处)。

创建新Target

每个后端在llvm/lib/Target下都有一个单独的目录，其中包含后端的大部分代码。 我们不会在这篇文章中深入讨论代码的细节(稍后我们会这样做) ，因为即使是一个很小的后端，比如RISCW，也有很多文件。 目前，我们可以将这些文件大致分为三类:

• TableGen文件LLVM目标无关代码生成框架实现了一个精心设计的模式匹配算法，用于为输入的程序选择指令。 待匹配的模式使用TableGen语法描述。 此外，TableGen文件还描述了target在体系结构方面的重要特性，如寄存器的数量和调用约定等。

• Build文件后端的每个目录都必须被声明，否则它将不会被构建。 此外，我们的后端的顶部目录(llvm/lib/Target/RISCW) ，以及每个子目录必须包含两个构建文件:CMakeLists.txt和LLVMBuild.txt， 前者将源文件和任何子目录添加为生成目标，而后者为生成目标设置简单的生成参数，参数包括生成目标的名称、链接所需的库等。

• C++文件包含了大量的后端代码，实现了从简单的配置选项到更复杂的指令选择功能(TableGen没有实现或不能实现)的所有功能。

建立实验性后端

现在，一切都已经建立，我们可以构建带有RISCW后端的LLVM。 但是我们不能简单地根据上一章的内容修改CMake的-DLLVM_TARGETS_TO_BUILD选项，以包含RISCW，因为后端仍处于试验阶段。 相反，我们使用-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD选项，如下:

cmake -G "Ninja" -DLLVM_ENABLE_PROJECTS="clang" -DLLVM_TARGETS_TO_BUILD="ARM;Lanai;RISCV" -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="RISCW" -DCMAKE_BUILD_TYPE="Debug" -DLLVM_ENABLE_ASSERTIONS=On ../llvm
ninja

当构建完成后，你可以检查RISCW现在是否是一个可用的后端，如下所示:

$ ./build/bin/llc --version
LLVM (http://llvm.org/):
  LLVM version 10.0.1
  DEBUG build with assertions.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: znver2

  Registered Targets:
    arm     - ARM
    armeb   - ARM (big endian)
    lanai   - Lanai
    riscv32 - 32-bit RISC-V
    riscv64 - 64-bit RISC-V
    riscw   - 32-bit RISC-V         <== YAY!!
    thumb   - Thumb
    thumbeb - Thumb (big endian)

编译C程序

我们的RISCW后端只能发出两条add和ret指令，而且它不能正确处理函数调用、堆栈和几乎所有其他的东西！ 因此，我们将约束自己，只编译这个小函数:

int test(int a, int b)
{
    return a + b;
}

就这样，我们得到了这样一个代码:

    .text
    .file   "test.c"
    .globl  test                    ; -- Begin function test
    .type   test,@function
test:                                   ; @test
; %bb.0:                                ; %entry
    add x0, x1, x0
    ret
.Lfunc_end0:
    .size   test, .Lfunc_end0-test
                                        ; -- End function
    .ident  "clang version 10.0.1 (https://github.com/llvm/llvm-project 89f2d2cc3bba7cb12cee346b3205cb0335e758cd)"
    .section    ".note.GNU-stack","",@progbits

有很多东西缺失了，代码实际上是不正确的，在RISCV中的x0是一个硬编码为0的只读寄存器。 但是我认为我们已经达到了目标: 建立了一个最小的LLVM后端，可以很容易地用更多的特性进行扩展。

注意:如果您使用上一篇文章中的命令来编译上面的测试函数，请确保为clang设置了-target riscw和为llc设置了-march=riscw。

注意:试图编译更复杂的程序将导致cannot select...错误。如果你感兴趣，就试一试。

注意:您可以通过将-debug选项传递给llc来指示编译器打印调试信息。

环境

我正在使用Ubuntu，但是你应该能够在其他系统中重复这些步骤，而且(相对来说)几乎没有什么不同。您将需要以下工具来构建软件。

• Makefile
• C/C++ Compiler – 我用 GCC 9.2.1
• autotools
• CMake
• Ninja
• Git
• 大量耐心

注意：我可能忘记了一些东西，但是构建系统会通过一个错误告诉您；

编译LLVM

LLVM维护者已经建立了这个方便的repo，它包含LLVM和工具链的其他部分，比如Clang。

git clone https://github.com/llvm/llvm-project

在本系列文章中，我们将使用llvm 10.0.1，我建议您也使用该版本的LLVM。 因为LLVM的变化非常快，这里显示的一些代码在旧/新版本中可能无法工作。 不过，原理应该大致相同。

LLVM使用CMake为构建系统生成构建文件，LLVM支持的构建系有：Ninja，Makefiles，Visual Studio和XCode。 我通常使用Ninja，因为我认为它在我的系统中速度最快（我没有证据支持该判断！）。 您可以通过cmake命令的-G参数来更改构建系统。

CMake有很多选项，我鼓励您对其进行研究，因为有些选项对调试非常有帮助。 您可以在这里阅读所有构建选项。 在本教程中，我将使用以下选项:

1. -DLLVM_ENABLE_PROJECTS 构建编译器的其余部分，比如Clang。

2. -DLLVM_TARGETS_TO_BUILD 指定要构建的后端。查看其他后端的输出对调试很有帮助，但是如果添加太多，构建会花费很长时间。

3. -DCMAKE_BUILD_TYPE 构建Debug版本。

4. -DLLVM_ENABLE_ASSERTIONS=On 启用断言，对调试很有帮助。

以下是在克隆repo之后构建LLVM的方法。

cd llvm-project
git checkout llvmorg-10.0.1
mkdir build
cd build
cmake -G "Ninja" -DLLVM_ENABLE_PROJECTS="clang" -DLLVM_TARGETS_TO_BUILD="ARM;Lanai;RISCV" -DCMAKE_BUILD_TYPE="Debug" -DLLVM_ENABLE_ASSERTIONS=On ../llvm
ninja

注意：您可以在这里和这里找到更多有关构建LLVM的信息。

注意：您可以为Ninja传递-j <NUM_JOBS>选项，以指示要并行的作业数。 过高的<NUM_JOBS>会导致构建崩溃，并产生collect2：ld ...错误消息。

编译RISC V的GNU工具链

你可能有点困惑，为什么我建议构建GCC的RISC V后端？ 难道我们不是要自己编写编译器后端吗？

我们构建GCC的RISC V后端，是因为我们希望在初始阶段使用GCC的汇编器和链接器来测试LLVM后端生成的代码。 编译过程分为很多阶段，在初始阶段，我们已经有以下结构:

• Clang 编译C代码到LLVM IR
• LLVM 优化IR
• LLVM后端 编译IR到汇编
• GCC 汇编和链接可执行文件

使用以下命令下载，构建和安装GCC for RISCV。

git clone https://github.com/riscv/riscv-gnu-toolchain
cd riscv-gnu-toolchain
mkdir build
cd build
../configure --with-arch=rv32gc --with-abi=ilp32
make
make install

注意：请确保为指令集的正确变体（即RV32）构建GCC工具链，因为构建系统的默认值为RV64！

注意：GNU工具链支持RISC V的多个ABI，例如ilp32，ilp32d和ilp32f，这取决于您是否需要软浮点，硬浮点。

编译C程序

现在，构建和运行C代码的环境已经配置好了，尽管我们还没自己的后端（还！）。让我们从一个简单的C程序开始：

#include <stdio.h>

int main(void)
{
    printf("Hello world!\n");
    return 0;
}

首先，使用Clang将C代码编译为LLVM IR。 我们的计划是使用标准库中来自头文件stdio.h的函数printf，如果不能找到头文件，编译器会提示出错。 为了使用GCC自带的RISC V标准C库，我们使用了-isystem参数。 这会将包含所需头文件的目录添加到Clang预处理器的搜索目录列表中。

clang -O2 -emit-llvm -target riscv64 -isystem <PATH_TO_GCC>/riscv64-unknown-elf/include -c test.c -o test.bc

上面的命令把C语言文件test.c编译到LLVM IR文件test.bc，这是专门为机器设计的语言人类很难直接阅读。 我们可以使用以下命令反汇编该文件：

llvm-dis test.bc

现在，使用包含以下内容的后端将IR编译为程序集，而无需使用以下命令下载LLVM： 现在，使用LLVM自带的后端将IR编译为程汇编：

llc -march=riscv64 -O2 -filetype=asm test.bc -o test.S

GCC可以直接生成程序的二进制文件。 我将其分为两个步骤，但是您可以根据需要使用单个命令。

riscv64-unknown-elf-gcc -c test.S -o test.o
riscv64-unknown-elf-gcc test.o -o test

最后，我们可以使用模拟器或真实硬件运行程序。

LLVM架构

传统上，编译过程分为三个阶段。 首先，编译器的前端将源代码转换为某种中间表示（IR）； 然后，优化IR； 最后，编译器的后端将IR转换为机器代码。 传统的编译器通常仅支持一种编程语言和一种目标指令集，编译器的源代码很难重用，例如添加新的目标指令集。

LLVM模块化地实现了三个编译过程，可以解决重用问题。 其思想是LLVM的核心（即IR和优化器）是固定的，但是前端和后端可以被替换，以使编译器可以支持多种编程语言和指令集。 例如，我们可以使用Clang（LLVM的前端）和x86后端把C/C++代码编译成X86指令集上的可执行程序。 我们也可以用ARM后端替换X86后端，从而得到ARM指令集上的可执行程序。

注意：LLVM的设计师Chris Lattner撰写了这篇文章介绍LLVM的体系结构及其设计动机。

注意：LLVM的这三个阶段的每个阶段在都有一个专用的可执行文件。 clang是C/C++的前端（显然针对不同的编程语言有不同的前端），opt是优化程序，llc用于调用后端。 通常，我们使用clang作为驱动程序来执行前端，使用llc和opt配合适当的参数来生成IR，汇编，可执行文件等。

代码生成

LLVM后端将IR编译为目标代码或汇编代码。 每个后端都只支持单一平台，但可以支持多个指令集。 例如，LLVM只有一个ARM后端，但该后端可以为ARMv6和ARMv7等指令集生成代码。 每个后端都建立在LLVM的目标无关代码生成器之上。 目标无关代码生成器是一个框架，可实现诸如寄存器分配之类的关键算法。 从广义上讲，后端的任务是配置该框架并使之适应其目标指令集的特定需求。

代码生成具有以下阶段：

1. 指令选择 映射LLVM IR到目标指令集中的指令。 此阶段使用无限数量的虚拟寄存器和函数调用堆栈的抽象引用。

2. 计划和编排 确定指令的顺序。 需要明确的是，在指令选择阶段已经对指令进行了排序，但这里可以根据寄存器分配策略或指令等待时间来对其中的一些指令的排序进行优化。

3. 基于SSA的机器代码优化 执行诸如peephole优化之类的工作。

4. 寄存器分配 将虚拟寄存器映射到物理寄存器。

5. Prolog / Epilog插入 在每个函数的开头（或prolog）和结尾（或epilog）插入机器指令。 这些通常是在进入或退出函数时扩展堆栈的指令。 由于当前已经知道堆栈大小，因此也可以解析抽象堆栈引用。

6. 后期机器代码优化 可能不言自明。

7. 代码发射 发出目标代码或汇编代码。

接下来，我将看一下构建LLVM以及如何设置开发/调试环境…

注意：您可以阅读这篇文章了解LLVM目标无关代码生成器的更多信息。

运行TableGen

TableGen的运行就像其他任何LLVM工具一样。 第一个（可选）参数指定要读取的文件。 如果未指定文件名，则llvm-tblgen从标准输入读取。

要使用TableGen就必须指定后端，这些后端可以在命令行中选择（输入“ llvm-tblgen -help”获取列表）。例如，要获取特定类型的子类的所有定义的列表(这对于构建这些记录的枚举很有用)，请使用print-enum选项：

$ llvm-tblgen X86.td -print-enums -class=Register
AH, AL, AX, BH, BL, BP, BPL, BX, CH, CL, CX, DH, DI, DIL, DL, DX, EAX, EBP, EBX,
ECX, EDI, EDX, EFLAGS, EIP, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6, IP,
MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, R10, R10B, R10D, R10W, R11, R11B, R11D,
R11W, R12, R12B, R12D, R12W, R13, R13B, R13D, R13W, R14, R14B, R14D, R14W, R15,
R15B, R15D, R15W, R8, R8B, R8D, R8W, R9, R9B, R9D, R9W, RAX, RBP, RBX, RCX, RDI,
RDX, RIP, RSI, RSP, SI, SIL, SP, SPL, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7,
XMM0, XMM1, XMM10, XMM11, XMM12, XMM13, XMM14, XMM15, XMM2, XMM3, XMM4, XMM5,
XMM6, XMM7, XMM8, XMM9,

$ llvm-tblgen X86.td -print-enums -class=Instruction
ABS_F, ABS_Fp32, ABS_Fp64, ABS_Fp80, ADC32mi, ADC32mi8, ADC32mr, ADC32ri,
ADC32ri8, ADC32rm, ADC32rr, ADC64mi32, ADC64mi8, ADC64mr, ADC64ri32, ADC64ri8,
ADC64rm, ADC64rr, ADD16mi, ADD16mi8, ADD16mr, ADD16ri, ADD16ri8, ADD16rm,
ADD16rr, ADD32mi, ADD32mi8, ADD32mr, ADD32ri, ADD32ri8, ADD32rm, ADD32rr,
ADD64mi32, ADD64mi8, ADD64mr, ADD64ri32, ...

默认后端打印出所有记录。 还有一个通用后端，它将所有记录输出为JSON数据结构，并使用-dump-json选项启用。

如果您计划使用TableGen，那么您很可能必须编写一个后端来提取您需要的信息并以适当的方式格式化它。可以通过用C++扩展TableGen本身，或者用任何可以处理JSON的语言编写脚本来实现这一点。

例子

在没有其他参数的情况下，llvm-tblgen 解析指定的文件并输出所有的类，然后输出所有的定义。这是查看各种定义扩展到何种程度的好方法。在 X86.td 文件上运行这个命令会输出以下命令(在撰写本文时) :

...
def ADD32rr {   // Instruction X86Inst I
  string Namespace = "X86";
  dag OutOperandList = (outs GR32:$dst);
  dag InOperandList = (ins GR32:$src1, GR32:$src2);
  string AsmString = "add{l}\t{$src2, $dst|$dst, $src2}";
  list<dag> Pattern = [(set GR32:$dst, (add GR32:$src1, GR32:$src2))];
  list<Register> Uses = [];
  list<Register> Defs = [EFLAGS];
  list<Predicate> Predicates = [];
  int CodeSize = 3;
  int AddedComplexity = 0;
  bit isReturn = 0;
  bit isBranch = 0;
  bit isIndirectBranch = 0;
  bit isBarrier = 0;
  bit isCall = 0;
  bit canFoldAsLoad = 0;
  bit mayLoad = 0;
  bit mayStore = 0;
  bit isImplicitDef = 0;
  bit isConvertibleToThreeAddress = 1;
  bit isCommutable = 1;
  bit isTerminator = 0;
  bit isReMaterializable = 0;
  bit isPredicable = 0;
  bit hasDelaySlot = 0;
  bit usesCustomInserter = 0;
  bit hasCtrlDep = 0;
  bit isNotDuplicable = 0;
  bit hasSideEffects = 0;
  InstrItinClass Itinerary = NoItinerary;
  string Constraints = "";
  string DisableEncoding = "";
  bits<8> Opcode = { 0, 0, 0, 0, 0, 0, 0, 1 };
  Format Form = MRMDestReg;
  bits<6> FormBits = { 0, 0, 0, 0, 1, 1 };
  ImmType ImmT = NoImm;
  bits<3> ImmTypeBits = { 0, 0, 0 };
  bit hasOpSizePrefix = 0;
  bit hasAdSizePrefix = 0;
  bits<4> Prefix = { 0, 0, 0, 0 };
  bit hasREX_WPrefix = 0;
  FPFormat FPForm = ?;
  bits<3> FPFormBits = { 0, 0, 0 };
}
...

该定义对应于x86体系结构的32位寄存器-寄存器相加指令。 Def ADD32rr定义了一个名为ADD32rr的记录，行尾的注释表示该定义的父类。 记录体包含TableGen为记录汇编的所有数据，指示该指令是“x86”命名空间的一部分，指示代码生成器如何选择指令的模式，它是双地址指令，具有特定的编码等。记录中信息的内容和语义专用于X86后端，这里仅作为示例。

正如您所看到的，代码生成器支持的每条指令都需要大量信息，手动指定所有指令将不可维护，容易出错，而且首先要做的事情很累人。因为我们正在使用 TableGen，所有的信息都来自以下定义:

let Defs = [EFLAGS],
    isCommutable = 1,                  // X = ADD Y,Z --> X = ADD Z,Y
    isConvertibleToThreeAddress = 1 in // Can transform into LEA.
def ADD32rr  : I<0x01, MRMDestReg, (outs GR32:$dst),
                                   (ins GR32:$src1, GR32:$src2),
                 "add{l}\t{$src2, $dst|$dst, $src2}",
                 [(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;

这个定义使用定制类 I (从定制类 X86Inst 扩展而来) ，这个定制类是在 x86特定的 TableGen 文件中定义的，可以提取了指令共享的公共特性。TableGen 的一个关键特性是，它允许最终用户定义他们在描述其信息时喜欢使用的抽象。

基本概念

TableGen文件由两个关键部分组成:“类”和“定义”，这两个部分都被认为是“记录”。

记录 有一个唯一的名称、一个值列表和一个父类列表。 值列表是TableGen为每条记录构建的主要数据；正是该列表保存了应用程序的特定信息。 此数据的解释留给特定的后端，但结构和格式规则由TableGen负责。

定义 是“记录”的具体形式。它通常不包含任何未定义的值，并用“ def”关键字进行标记。

def FeatureFPARMv8 : SubtargetFeature<"fp-armv8", "HasFPARMv8", "true",
                                      "Enable ARMv8 FP">;

在此示例中，FeatureFPARMv8是使用某些值初始化的SubtargetFeature记录。 这些类通过关键字class定义在同一文件或其他文件中的。 对大多数平台来说，包含通用类的TableGen文件保存在include/llvm/Target中。

class 是用于构建和描述其他记录的抽象记录。这些类使最终用户可以为他们所针对的领域（例如LLVM代码生成器中的“ Register”，“ RegisterClass”和“ Instruction”）构建抽象，提取改领域的公共属性（例如“ FPInst”，用于表示X86后端中的浮点指令）。TableGen会跟踪用于建立定义的所有类，因此后端可以找到特定类的所有定义，例如“instruction”。

class ProcNoItin<string Name, list<SubtargetFeature> Features>
      : Processor<Name, NoItineraries, Features>;

在这里，类ProcNoItin通过类型为string的参数名、目标特性列表和硬编码的NoItineraries来特化Processor类。

multiclass 一次实例化一组抽象记录。每个实例化都会产生多个TableGen定义。如果一个multiclass继承了另一个multiclass，那么子multiclass中的定义将成为当前multiclass的一部分，就像它们是在当前multiclass中声明的一样。

multiclass ro_signed_pats<string T, string Rm, dag Base, dag Offset, dag Extend,
                        dag address, ValueType sty> {
def : Pat<(i32 (!cast<SDNode>("sextload" # sty) address)),
          (!cast<Instruction>("LDRS" # T # "w_" # Rm # "_RegOffset")
            Base, Offset, Extend)>;

def : Pat<(i64 (!cast<SDNode>("sextload" # sty) address)),
          (!cast<Instruction>("LDRS" # T # "x_" # Rm # "_RegOffset")
            Base, Offset, Extend)>;
}

defm : ro_signed_pats<"B", Rm, Base, Offset, Extend,
                      !foreach(decls.pattern, address,
                               !subst(SHIFT, imm_eq0, decls.pattern)),
                      i8>;

有关TableGen的深入描述，请参阅TableGen的TableGen Programmer’s Reference。

4.1 定义寄存器

XXXRegisterinfo.td文件通常以目标机器的寄存器定义开始。Register类(在Target.td中定义)用于为每个寄存器定义一个对象。字符串n就是寄存器的名称。基本的Register对象不包含子寄存器，也没有指定别名。

class Register<string n> {
  string Namespace = "";
  string AsmName = n;
  string Name = n;
  int SpillSize = 0;
  int SpillAlignment = 0;
  list<Register> Aliases = [];
  list<Register> SubRegs = [];
  list<int> DwarfNumbers = [];
}

例如，X86RegisterInfo.td文件使用Register类定义寄存器。比如：

def AL : Register<"AL">, DwarfRegNum<[0, 0, 0]>;

这行代码定义了寄存器AL并使用DwarfRegNum为其赋值，gcc，gdb或其他调试信息工具用该值来识别寄存器。对于AL寄存器来说，DwarfRegNum使用了一个由3个值组成的数组，用来表示3 种不同的模式：第一个值是用于X86-64，第二个值用于X86-32中的异常处理（exception handling），第三个是通用值。-1表示gcc的值未定义，-2表示寄存器在该模式下是非法的。

根据X86RegisterInfo.td文件的描述，TableGen会在X86GenRegisterInfo.inc文件中生成以下代码：

static const unsigned GR8[] = { X86::AL, ... };

const unsigned AL_AliasSet[] = { X86::AX, X86::EAX, X86::RAX, 0 };

const TargetRegisterDesc RegisterDescriptors[] = {
  ...
{ "AL", "AL", AL_AliasSet, Empty_SubRegsSet, Empty_SubRegsSet, AL_SuperRegsSet }, ...

根据register info文件，TableGen为每个寄存器生成一个TargetRegisterDesc对象。TargetRegisterDesc在include/llvm/Target/Target.h中被定义，包含以下字段：

struct TargetRegisterDesc {
  const char     *AsmName;      // Assembly language name for the register
  const char     *Name;         // Printable name for the reg (for debugging)
  const unsigned *AliasSet;     // Register Alias Set
  const unsigned *SubRegs;      // Sub-register set
  const unsigned *ImmSubRegs;   // Immediate sub-register set
  const unsigned *SuperRegs;    // Super-register set
};

TableGen使用名称(TargetRegisterDesc的AsmName和Name字段)以及寄存器间的关系(TargetRegisterDesc的其他字段)来定义寄存器。在这个示例中，寄存器“AX”、“ EAX”和“RAX”为彼此的别名，TableGen为这个寄存器别名集生成一个以null结尾的数组(AL_aliasset)。

Register类通常用作更复杂类的基类。在Target.td中，Register类是RegisterWithSubRegs类的基类，该类用于定义需要在SubRegs列表中指定子寄存器的寄存器，如下所示

class RegisterWithSubRegs<string n, list<Register> subregs> : Register<n> {
  let SubRegs = subregs;
}

SparcRegisterInfo.td为SPARC定义了额外的寄存器类：register类的子类SparcReg和其进一步的子类：Ri、Rf和Rd。SPARC的寄存器由5位ID号标识，这是这些子类的一个共同特性。“let”表达式可以覆盖最初在父类中定义的值（例如Rd类中的subgros字段）。

class SparcReg<string n> : Register<n> {
  field bits<5> Num;
  let Namespace = "SP";
}
// Ri - 32-bit integer registers
class Ri<bits<5> num, string n> :
SparcReg<n> {
  let Num = num;
}
// Rf - 32-bit floating-point registers
class Rf<bits<5> num, string n> :
SparcReg<n> {
  let Num = num;
}
// Rd - Slots in the FP register file for 64-bit floating-point values.
class Rd<bits<5> num, string n, list<Register> subregs> : SparcReg<n> {
  let Num = num;
  let SubRegs = subregs;
}

SparcRegisterInfo.td文件利用Register类的子类来定义寄存器，例如

def G0 : Ri< 0, "G0">, DwarfRegNum<[0]>;
def G1 : Ri< 1, "G1">, DwarfRegNum<[1]>;
...
def F0 : Rf< 0, "F0">, DwarfRegNum<[32]>;
def F1 : Rf< 1, "F1">, DwarfRegNum<[33]>;
...
def D0 : Rd< 0, "F0", [F0, F1]>, DwarfRegNum<[32]>;
def D1 : Rd< 2, "F2", [F2, F3]>, DwarfRegNum<[34]>;

上面显示的最后两个寄存器(D0和D1)是双精度浮点寄存器，它们是单精度浮点子寄存器对的别名。除了别名之外，子寄存器和父寄存器的关系也定义在TargetRegisterDesc的某些字段中。

4.2 定义寄存器组

RegisterClass类（在Target.td中指定）用于定义一个对象， 该对象表示一组相关的寄存器， 还定义了寄存器的默认分配顺序。 使用Target.td的目标描述文件XXXRegisterInfo.td可以使用以下类构造寄存器组：

class RegisterClass<string namespace,
list<ValueType> regTypes, int alignment, dag regList> {
  string Namespace = namespace;
  list<ValueType> RegTypes = regTypes;
  int Size = 0;  // spill size, in bits; zero lets tblgen pick the size
  int Alignment = alignment;

  // CopyCost is the cost of copying a value between two registers
  // default value 1 means a single instruction
  // A negative value means copying is extremely expensive or impossible
  int CopyCost = 1;
  dag MemberList = regList;

  // for register classes that are subregisters of this class
  list<RegisterClass> SubRegClassList = [];

  code MethodProtos = [{}];  // to insert arbitrary code
  code MethodBodies = [{}];
}

要定义RegisterClass，请使用以下4个参数:

• 第一个参数定义了命名空间的名称。

• 第二个参数是寄存器类型的列表，寄存器的类型定义在文件include/llvm/CodeGen/ValueTypes.td中。 已定义的值包括整数类型(i16、i32和i1(布尔值))、浮点类型(f32、f64)和向量类型(例如，v8i16表示8xi16向量)。 RegisterClass中的所有寄存器必须具有相同的ValueType， 但有些寄存器可以不同的配置存储向量数据。 例如，一个能够处理128位向量的寄存器也能处理16个8位整数元素，8个16位整数，4个32位整数，等等。

• 第三个参数指定寄存器数据在load或save时所需的对齐方式。

• 最后一个参数regList指定这个集合包含的寄存器。 如果没有指定寄存器的分配顺序， 那么regList还暗含了寄存器的分配顺序。 除了简单地用(add R0，R1，...)列出寄存器之外， 还可以用更高级的集合操作符。 更多信息，请参见include/llvm/Target/Target.td。

在SparcRegisterInfo.td中， 定义了三个RegisterClass对象：FPReg，DFPReg和IntReg。 对于所有三个寄存器类，第一个参数都是使用字符串“ SP”定义名称空间。 FPRegs定义了一组32个单精度浮点寄存器（F0至F31）。 DFPRegs定义了一组16个双精度寄存器（D0-D15）。

// F0, F1, F2, ..., F31
def FPRegs : RegisterClass<"SP", [f32], 32, (sequence "F%u", 0, 31)>;

def DFPRegs : RegisterClass<"SP", [f64], 64,
                            (add D0, D1, D2, D3, D4, D5, D6, D7, D8,
                                 D9, D10, D11, D12, D13, D14, D15)>;

def IntRegs : RegisterClass<"SP", [i32], 32,
    (add L0, L1, L2, L3, L4, L5, L6, L7,
         I0, I1, I2, I3, I4, I5,
         O0, O1, O2, O3, O4, O5, O7,
         G1,
         // Non-allocatable regs:
         G2, G3, G4,
         O6,        // stack ptr
         I6,        // frame ptr
         I7,        // return address
         G0,        // constant zero
         G5, G6, G7 // reserved for kernel
    )>;

TableGen将SparcRegisterInfo.td编译成多个输出文件， 这些输出文件将会被包含在您编写的其他源代码中。 SparcRegisterInfo.td被编译成SparcGenRegisterInfo.h.inc， 这个文件将被包含在实现SPARC寄存器的头文件SparcRegisterInfo.h中。 SparcGenRegisterInfo.h.inc定义了一个名为SparcGenRegisterInfo的新结构， 该结构继承TargetRegisterInfo， 还根据预定义的寄存器集（DFPRegsClass，FPRegsClass和IntRegsClass）来指定类型。

Sparcregisterinfo.td还会生成SparcGenRegisterInfo.inc文件， 它被包含在文件SparcRegisterInfo.cpp的底部， 该文件用于实现Sparc的寄存器。 下面只显示生成的整数寄存器和关联的寄存器集， IntRegs中寄存器的顺序同目标描述文件中IntRegs定义的顺序一致。

// IntRegs Register Class...
static const unsigned IntRegs[] = {
  SP::L0, SP::L1, SP::L2, SP::L3, SP::L4, SP::L5,
  SP::L6, SP::L7, SP::I0, SP::I1, SP::I2, SP::I3,
  SP::I4, SP::I5, SP::O0, SP::O1, SP::O2, SP::O3,
  SP::O4, SP::O5, SP::O7, SP::G1, SP::G2, SP::G3,
  SP::G4, SP::O6, SP::I6, SP::I7, SP::G0, SP::G5,
  SP::G6, SP::G7,
};

// IntRegsVTs Register Class Value Types...
static const MVT::ValueType IntRegsVTs[] = {
  MVT::i32, MVT::Other
};

namespace SP {   // Register class instances
  DFPRegsClass    DFPRegsRegClass;
  FPRegsClass     FPRegsRegClass;
  IntRegsClass    IntRegsRegClass;
...
  // IntRegs Sub-register Classes...
  static const TargetRegisterClass* const IntRegsSubRegClasses [] = {
    NULL
  };
...
  // IntRegs Super-register Classes..
  static const TargetRegisterClass* const IntRegsSuperRegClasses [] = {
    NULL
  };
...
  // IntRegs Register Class sub-classes...
  static const TargetRegisterClass* const IntRegsSubclasses [] = {
    NULL
  };
...
  // IntRegs Register Class super-classes...
  static const TargetRegisterClass* const IntRegsSuperclasses [] = {
    NULL
  };

  IntRegsClass::IntRegsClass() : TargetRegisterClass(IntRegsRegClassID,
    IntRegsVTs, IntRegsSubclasses, IntRegsSuperclasses, IntRegsSubRegClasses,
    IntRegsSuperRegClasses, 4, 4, 1, IntRegs, IntRegs + 32) {}
}

寄存器分配器将避免使用保留寄存器， 并且被调用方保存的寄存器在所有易失性寄存器被使用之前都不会被使用。 这通常已经足够好了， 但在某些情况下， 可能需要提供自定义分配命令。

4.3 实现TargetRegisterInfo的子类

最后一步是手工编写XXXRegisterInfo的部分代码， 它实现了文件TargetRegisterInfo.h描述的接口（请参见TargetRegisterInfo类）。 如果不实现这些接口，这些接口将返回0、NULL或false。 下面是为实现SPARC而在文件SparcRegisterInfo.cpp中手工编写函数列表:

• getCalleeSavedRegs —- 返回被叫方保存的寄存器列表，按被叫方所需的堆栈帧偏移量顺序。

• getReservedRegs —- 返回物理寄存器索引的集合，指示特定寄存器是否不可用。

• hasFP —- 返回一个布尔值，指示函数是否应具有专用的帧指针寄存器。

• eliminateCallFramePseudoInstr —- 如果使用调用帧设置或销毁伪指令，则可以调用此命令来消除它们。

• excludeFrameIndex – 从能使用抽象帧索引的指令中删除抽象帧索引。

• emitPrologue – 在函数中插入Prologue代码。

• emitEpilogue – 在函数中插入Epilogue代码。

指令操作数映射

指令调度

指令关系映射

实现TargetStrInfo的子类

分支折叠与If转换

选择合法化阶段

调用约定

机器码发射器

目标JIT信息