LLVM 3.0 类型系统重写

类型系统的目标

类型系统有一些重要的需求限制了它的设计：我们希望能够使用有效的指针相等性检查来确定结构类型相等性，我们希望允许类型延迟细化（例如在链接时，一个模块应该能够完成另一个模块中的类型），我们希望它易于表达许多不同的源语言，并且我们希望一个简单且可预测的系统。

IR 类型系统中唯一真正困难的部分是处理类型的转发声明。要了解这一点，请观察到类型系统实际上是由一个复杂的类型图表示的（该图通常是循环的）。例如，一个简单的整数单向链表可能像这样声明

  %intlist = type { %intlist*, i32 }

有了这个背景，让我们先谈谈 LLVM 2.9 及更早版本是如何工作的。

旧的类型系统

  %T1 = type opaque
  %T2 = type %T1*

变异和移动类型的后果

另一个问题是，不仅仅是类型需要更新：包含指向类型的指针的任何内容都必须更新，否则就会出现悬空指针。这个问题以多种方式表现出来：例如，每个 Value 都有一个指向类型的指针。为了使系统更高效，Value::getType() 实际上执行了一个延迟的“并查集”步骤，以确保它始终返回一个规范化和唯一的类型。这使得 Value::getType()（一个非常常见的调用）比它应该的更昂贵。

这种“类型更新”问题造成的更严重的问题是，当您通过 LLVM API 操作和构建 IR 时。由于类型可以移动，因此很容易获得悬空指针，从而导致很多混乱和很多 LLVM API 的损坏客户端。这还因为构建 简单递归类型 需要使用类型细化。我们尝试用 PATypeHolder 和 PATypeHandle 类来简化这一点，但它们只有在你正确使用它们时才有效，而且通常人们对它们了解不多。

类型唯一化带来的意外行为

  %T1 = type opaque
  @G1 = external global %T1*

  %T2 = type {}
  @G2 = external global %T2*

  %T1 = type {}
  @G1 = external global %T1*

  %T2 = type {}
  @G2 = external global %T1*

类型上引用

类型上引用是一个优雅的解决方案，它允许 asmprinter（和解析器）能够在有限的空间内表示任意的递归类型，而不需要名称。例如，上面的 %intlist 示例可以表示为“{\2*, i32}”。它还允许构建一些不错（但令人惊讶）的类型，比如“\1*”，它是一个指向自身的指针！

尽管具有一定的美感和优雅，但大多数人并不理解类型上引用，而且它们也引起了很多混乱。能够从 LLVM IR 模块中剥离名称很重要（例如 -strip 传递），但也同样重要的是让编译器黑客能够理解这个系统！

为新的类型系统做准备

  %0 = type { %0*, i32 }

LLVM 3.0 类型系统

简而言之，LLVM 3.0 不是基于细化的类型系统，在该系统中类型在内存中变异（需要重新唯一化以及指针的移动/更新），而是使用了类似于 C 中使用的类型系统，该系统基于类型完成。基本上，您现在不是创建不透明类型然后稍后替换它，而是创建一个没有主体结构的 StructType，然后稍后指定主体。要创建 %intlist 类型，您现在可以这样写

  StructType *IntList = StructType::create(SomeLLVMContext, "intlist");
  Type *Elts[] = { PointerType::getUnqual(IntList), Int32Type };
  IntList->setBody(Elts);

只有结构类型可以是递归的

字面结构体和已标识结构体

已标识结构体是我们正在讨论的类型：它们可以有名称，并且可以在创建类型后指定其主体。已标识结构体不会与其他结构类型进行唯一化，这就是它们使用 StructType::create(...) 创建的原因。由于已标识类型可能是递归的，因此 asmprinter 始终按其名称（或一个数字，比如 %42，如果已标识结构体没有名称）打印它们。

字面结构类型与旧的 IR 结构类型类似：它们永远没有名称，并且通过结构标识进行唯一化：这意味着它们必须在构建时提供主体元素，而且它们永远不能是递归的。当被 asmprinter 打印时，它们总是内联打印，没有名称。字面结构类型由 StructType::get(...) 方法创建，这反映了它们是唯一的（调用可能实际分配一个新的 StructType，也可能不分配）。

我们预计已标识结构类型将是最常见的类型，并且前端只会生成字面结构类型以用于特殊情况。例如，对于元组、复数和其他简单情况，使用字面结构类型是合理的，在这些情况下，名称是任意的，而且会使 IR 更难阅读。优化器对此并不关心，因此如果您是前端的作者，请使用您在 IR 导出中想看到的任何内容。

已标识结构体与名称一一对应

结构体名称在 LLVMContext 级别上唯一化

链接器 "链接" 类型并重新类型化 IR 对象。

x.ll:
  %A = type { i32 }
  @G = external global %A
y.ll:
  %A = type { i32 }
  @G = global %A zeroinitializer

x.ll module:
  %A = type { i32 }
  @G = external global %A
y.ll module:
  %A.1 = type { i32 }
  @G = global %A.1 zeroinitializer

将此逻辑放在 IR 链接器中而不是 VMCore 中，在很多方面都比之前的设计更好：现在，合并和唯一化的成本只由 IR 链接器承担，而不是由所有位码读取和其他 IR 创建代码承担。代码更容易理解和算法优化，因为我们正在一次合并两个完整的图——而不是逐个解析类型。最后，这通过将一些复杂的逻辑从 VMCore 中移除来缩减了 VMCore 的大小。

在优化器（或更晚）中识别神奇的 IR 类型

在优化器（或前端运行后的其他位置）中识别特定类型的更健壮方法是使用命名元数据节点查找类型。例如，如果您要查找 %foo 类型，您可以生成如下所示的 IR

  %foo = type { ... }
  ...
  !magic.types = !{ %foo zeroinitializer }

命名元数据似乎存在一些混淆：与指令级元数据不同，它们不会被优化器传递丢弃或使之无效（只要它们不指向被优化器修改的函数或其他 IR 对象）。一般来说，命名元数据是将信息从前端传递到优化器或后端的一种比尝试使用类型名称玩游戏好得多、多得多、多得多的方法。

结论

-Chris Lattner