gcc - GCC IR与LLVM IR有何不同？

Question

人们为什么偏爱LLVM IR，它与GCC IR有何不同？目标依赖性是这里的一个因素吗？

我是编译器的新手，即使经过数小时的寻找答案，也找不到任何相关的内容。任何见解都会有所帮助。

Answer 1

首先，由于这个答案涉及到复杂而敏感的主题，因此我希望免责声明：


我认为您的问题是关于LLVM和GCC的中端IR（因为“ LLVM IR”一词仅适用于中端）。讨论后端IR（LLVM MachineIR和GCC RTL）和相关代码生成工具（LLVM Tablegen和GCC Machine Description）之间的差异是一个有趣且重要的话题，但答案会大很多倍。
我省去了基于库的LLVM设计与GCC的整体设计，因为它与IR本身是独立的（尽管相关）。
我喜欢在GCC和LLVM上进行黑客攻击，但我不敢一一列举。 LLVM之所以如此，是因为人们可以从GCC在2000年代出错的事情中学习（从那时起，情况有了很大的改善）。
我很高兴改善此答案，因此，如果您认为某些内容不正确或缺少，请发表评论。


最重要的事实是LLVM IR和GCC IR（称为GIMPLE）在内核上并没有什么不同-都是基本块的标准控制流程图，每个块都是2个输入，1个输出指令的线性序列（所谓的“三地址代码”）已转换为SSA form。自1990年代以来，大多数生产编译器一直在使用这种设计。

LLVM IR的主要优点是它与编译器实现的绑定更紧密，定义更正式，并且具有更好的C ++ API。这使得处理，转换和分析更加容易，这使得它成为当今编译器和其他相关工具的首选。

我将在下面的子章节中详细介绍LLVM IR的优势。

独立红外

LLVM IR最初设计为可在除编译器本身之外的所有工具之间完全重用。 original intent用于多级优化：因此，IR将在运行时由提前编译器，链接时优化器和JIT编译器进行优化。这没有解决，但是可重用性还有其他重要意义，最明显的是，它允许轻松集成其他类型的工具（静态分析仪，仪器等）。

除了编译器之外，GCC社区从未希望启用任何工具（Richard Stallman拒绝尝试使IR更可重用，以防止第三方商业工具重用GCC的前端）。因此，从未将GIMPLE（GCC的IR）视为实现细节，尤其是它没有提供已编译程序的完整描述（例如，它缺少程序的调用图，类型定义，堆栈偏移和别名信息）。

灵活的管道

可重用性和使IR成为独立实体的想法在LLVM中产生了重要的设计结果：编译过程可以以任何顺序运行，以防止复杂的过程间依赖（必须通过分析过程来明确所有依赖），并使实验更加容易与编译管道，例如


每次通过后都要进行严格的IR验证检查
bisecting pipeline查找导致编译器崩溃的最小传递子集
通行证的模糊顺序


更好的单元测试支持

独立的IR允许LLVM使用IR级别的单元测试，从而可以轻松测试优化/分析案例。通过C / C ++片段（如在GCC测试套件中）很难做到这一点，即使在您进行管理时，生成的IR也很可能在以后的编译器版本中发生重大变化，并且测试所针对的特殊情况将不再被掩盖。

简单的链接时间优化

独立IR通过后续（整个程序）优化实现简单的combination of IR from separate translation units。这不能完全替代链接时间优化（因为它不能解决生产软件中出现的可伸缩性问题），但通常对于较小的程序（例如在嵌入式开发或研究项目中）已经足够了。

红外清晰度更高

尽管criticized by academia，但LLVM IR的semantics比GIMPLE严格得多。这简化了各种静态分析器的实现，例如IR Verifier。

无中间IR

LLVM IR由前端（Clang，llgo等）直接生成，并在整个中端保留。这意味着所有工具，优化和内部API仅需在单个IR上运行。对于GCC，情况并非如此-甚至GIMPLE也具有三个不同的变体：


高GIMPLE（包括词汇范围，高级控制流构造等）
低SSA前的GIMPLE
最终的SSA GIMPLE和GCC前端通常会生成中间GENERIC IR而不是GIMPLE。


红外更简单

与GIMPLE相比，通过减少IR消费者需要考虑的案例数量，故意使LLVM IR更加简单。我在下面添加了几个示例。

显式控制流

LLVM IR程序中的所有基本块都必须以显式控制流操作码（分支，goto等）结尾。不允许隐式控制流（即掉线）。

显式堆栈分配

在LLVM IR中，虚拟寄存器没有内存。堆栈分配由专用的alloca操作表示。这简化了使用堆栈变量（例如不需要等价于GCC的ADDR_EXPR。

显式索引操作

与GIMPLE相反，GIMPLE具有大量用于内存引用的操作码（INDIRECT_REF，MEM_REF，ARRAY_REF，COMPONENT_REF等），而LLVM IR仅具有简单的加载和存储操作码，所有复杂的算法都移至专用的结构化索引操作码getelementptr。

垃圾收集支持

LLVM IR为垃圾收集的语言提供了dedicated pseudo-instructions。

高级实现语言

尽管C ++可能不是最好的编程语言，但它绝对可以编写更简单（在许多情况下，更多功能）的系统代码，
特别是在C ++ 11之后的版本中（LLVM积极采用新标准）。继LLVM之后，GCC也采用了C ++，但是大多数代码库仍是用C风格编写的。

C ++启用了更简单的代码的实例太多了，因此我仅举几个例子。

显式等级

LLVM中的运算符层次结构是通过标准继承和template-based custom RTTI实现的。另一方面，GCC通过旧式继承（通过聚合）实现相同功能

// Base class which all operators aggregate
struct GTY(()) tree_base {
  ENUM_BITFIELD(tree_code) code : 16;

  unsigned side_effects_flag : 1;
  unsigned constant_flag : 1;
  unsigned addressable_flag : 1;

  ...  // Many more fields
};

// Typed operators add type to base data
struct GTY(()) tree_typed {
  struct tree_base base;
  tree type;
};

// Constants add integer value to typed node data
struct GTY(()) tree_int_cst {
  struct tree_typed typed;
  HOST_WIDE_INT val[1];
};

// Complex numbers add real and imaginary components to typed data
struct GTY(()) tree_complex {
  struct tree_typed typed;
  tree real;
  tree imag;
};

// Many more operators follow
...

和标记的联合范例：

union GTY ((ptr_alias (union lang_tree_node),
            desc ("tree_node_structure (&%h)"), variable_size)) tree_node {
  struct tree_base GTY ((tag ("TS_BASE"))) base;
  struct tree_typed GTY ((tag ("TS_TYPED"))) typed;
  struct tree_int_cst GTY ((tag ("TS_INT_CST"))) int_cst;
  struct tree_complex GTY ((tag ("TS_COMPLEX"))) complex;

所有GCC操作员API都使用基本的 tree类型，可通过 fat宏接口（ DECL_NAME， TREE_IMAGPART等）访问该类型。仅在运行时验证接口（并且仅当GCC配置了 --enable-checking时），并且不允许静态检查。

更简洁的API

LLVM通常为优化器中的模式匹配IR提供更简单的API。例如在GCC中检查指令是否为常数加法

  if (gimple_assign_p (stmt)
      && gimple_assign_rhs_code (stmt) == PLUS_EXPR
      && TREE_CODE (gimple_assign_rhs2 (stmt)) == INTEGER_CST)
    {
      ...

在LLVM中：

  if (auto BO = dyn_cast<BinaryOperator>(V))
  if (BO->getOpcode() == Instruction::Add
      && isa<ConstantInt>(BO->getOperand(1))
    {

任意精度算法

由于C ++对重载的支持，LLVM可以对所有计算使用任意精度的整数，而GCC仍使用物理整数（ HOST_WIDE_INT类型，在32位主机上为32位）：

  if (!tree_fits_shwi_p (arg1))
    return false;

  *exponent = tree_to_shwi (arg1);

如示例中所示，这可能导致错过优化。

几年前，GCC获得了 APInt的等价物，但是大多数代码库仍使用 HOST_WIDE_INT。