有关于TableGen的简单介绍

本文主要参考了官方的一篇文档：https://llvm.org/docs/TableGen/，因为工作相关，需要整理学习一下llvm中TableGen的相关知识，本文不是对官方文档的直接翻译，故仅供参考。

有关于LLVM的基础知识，可以参考我之前的文章：LLVM基本概念入门
有任何建议或疑问，欢迎留言或e-mail我：ylm1205@163.com

文章目录

基本介绍
基本操作方法
td文件的格式
- 语法
TableGen后端
TableGen 的不足之处

基本介绍

TableGen在llvm中是一个比较重要的部分，它连接着很多不同功能的模块，它的主要目的是帮助开发人员更便捷的维护领域特定信息（domain-specific information），比如说和目标机器平台相关的信息，或者和编程语言相关的信息，它可以帮助开发人员在编译器开发过程中减小冗余代码，降低维护修改难度，以及提供更好的开发框架来有利于扩充信息。

TableGen是llvm中的一个组成部分，它的功能就是读取一个文件（td文件），解析这个文件，输出成不同的结果文件（比如说C++语法的.inc后缀文件）。现在来说，其服务的功能模块主要有2个，分别是LLVM后端的平台不相关的代码生成（target independent code generator）阶段，以及Clang前端的代码诊断功能。

LLVM源码中提供了vim和emacs的一些配置文件，可以辅助更好的编辑TableGen的文件。

基本操作方法

LLVM中有一个工具，叫做llvm-tblgen，可以协助我们更容易的开展TableGen的开发工作。这个工具在正常的编译流程中是不参与的，只是额外的开发工具。它可以用来调度起整个TableGen的工作流。

以下是一些示例：

$ llvm-tblgen X86.td -print-enums -class=Register

这个命令指定llvm-tblgen处理x86处理器架构下的td文件，并打印出其中所有寄存器类中enum值的列表信息。

$ llvm-tblgen X86.td -print-enums -class=Instruction

这个命令指定llvm-tblgen处理x86处理器架构下的td文件，并打印出其中所有指令类中enum值的列表信息。

需要注意的是，虽然这里只指定了一个叫X86.td的文件，但实际上包含的可能是多个td文件，因为td文件可以include其他td文件，一般来说，<TargetName>.td文件时所有td文件的入口。

示例中的-print-enums是打印一个enum值的参数，这个参数指定的功能在TableGen中叫做一个TableGen后端（在官方文档中被直接称作backends，所以容易和编译器的后端混淆），除了这个后端之外，还有其他后端，如：-print-records是打印所有记录（也是不指定特殊后端时的默认后端）、-dump-json是打印JSON格式的所有记录、-gen-emitter是生成机器代码的输出，还有其他很多后端，就不一一列举，可以通过输入：

$ llvm-tblgen -help

来查看。

开发TableGen部分的内容时，除了修改td文件以外，还有可能修改后端，可以直接用C++在代码中修改，也可以写脚本处理JSON格式的文本。

如果不指定后端，那默认就是-print-records后端，也就是打印出所有的td文件中的记录，可以有助于我们检查td文件开发工作的完整性和正确性。

td文件的格式

第一次打开td文件时，有点懵，看不太懂，td文件的语法格式和C++的模板类比较像，同时它也做了一些扩展，比如multiclass、let等。

另外，看懂td文件还需要懂dag的描述格式、懂目标平台的指令格式、寄存器约束等、还需要懂一些指令选择的实现原理。

语法

td文件包括两个主要的关键词：class和def，class还扩展出了multiclass，对应的def也就扩展出了defm。这些条目被叫做记录（records）。

TabelGen的每一条记录都有一个唯一独立的名字，值的列表以及父类（superclass）的列表，它是支持重载的。

对于def/defm来说，它是对class/multiclass的实现，所有信息必须是确定的，语法如：

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

在这个例子中，FeatureFPARMv8是记录的名称，这条记录是SubtargetFeature类的实现，后边尖括号中的值是实例化class时的参数，参数的意义需要到其对应的class，也就是SubtargetFeature类的定义处查看。

class是td文件中抽象的记录描述，用来实现多个记录通用的部分，也可以实现一些能够析出记录信息的辅助功能，语法如：

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

这个例子中，ProcNoItin接受一些参数，并且继承Processor，并且将部分参数传入Processor。

TableGen的multiclass能够用来简化语法，可以同时实现一组相似的抽象记录。如果一个multiclass继承了另一个multiclass，那么这两个multiclass的属性会合并，就像在一个multiclass中声明所有属性一样。

有两篇详细的参考文档：TableGen Language Introduction：更多关于使用TableGen语言的详细描述、TableGen Language Reference：一些语言规范的深入说明，可供参考。
第一篇文章可以参考我的解读和学习：P2Tree的CSDN - TableGen 语言语法介绍。

TableGen后端

TableGen后端和编译器后端不同，它是用来处理TableGen语法文件的，可以将这些领域相关信息翻译成任何需要的信息格式，我们可以编写自己的后端。使用llvm-tblgen时不指定后端时的默认后端是将所有.td文件的信息打印成文本格式输出。

当前一个主要的配合编译器的TableGen后端是将td文件解析成一些C风格的接口，后缀名是.inc，这些文件不必要修改，因为每次build时都会重新根据td文件生成，这些文件会被其他一些文件所包含(#include)，进而作为支撑的领域相关信息被使用。

有一篇详细的参考文档：TableGen BackEnds，这篇文档我建议入门TableGen的使用之后再读，里边涉及到TableGen工具的工作机制，如果单纯为了使用TableGen描述后端信息，这篇文章不用深入研究。

TableGen 的不足之处

最后教程中提到了TableGen的一些不足，我就特别喜欢这种对技术的严谨（不像某些技术，单纯的夸自己多能耐），自身对自己的缺陷有清晰的认识之后，才能有更加明确的发展方向和目标，每个做技术的人都应该由这种态度。

TableGen的一个缺点是，因为领域相关信息都是比较多的，把这些信息都放到td文件中，会让整个文件显得不易维护，也会更复杂。确实，td文件可以互相包含，所以像现在的做法是把不同部分的信息分开，比如平台相关属性放到<target>.td、寄存器相关记录放到<target>RegisterInfo.td、指令相关记录放到<target>InstrInfo.td和<target>InstrFormat.td中等等，然鹅，即使这样，每个文件依然很大，就拿我看的ARM平台的td文件，普遍都是大几千行上万行一个文件，而且由于class的灵活性和平台相关信息的复杂多样性，最后导致整个文件的信息理解起来很费劲（ARM的架构很复杂，初学建议去看Mips，td文件也相对简单一些）。

另外，TableGen允许我们编写自己的后端，灵活的输入配合上灵活的后端，使得TableGen变得过于自由，这会影响到TableGen的设计思想，以及让新人很难上手这块工作。

总之，这块的缺陷llvm社区依然在讨论着，也许很快就会解决。

参考网址：TableGen Deficiencies