Compile Principle on Anfsity

编译优化其二-支配树

Mon, 08 Jun 2026 03:34:49 +0800

Introduction

支配树在编译器中最主要的作用是用于计算支配边界，用于插入 $\phi$ 函数，将 ir 提升到 SSA 形式。以及提供循环优化，DCE 等 pass 需要的结构信息。

Control Flow Graph

有如下代码：

int main () {

  int a = 1;
  a = fac(9);

  if (a == 1) {
    a = 2;
  } else {
    a = 4;
  }

  return a;
}

我们可以构建出 ir：

func @main() : () -> i32 {
  ^entry_0:
    %0 = alloca : i32 -> i32*
    store 1, %0 : i32, i32*
    %1 = call @fac(9) : (i32) -> i32
    store %1, %0 : i32, i32*
    %2 = eq %1, 1 : i32 -> i1
    branch %2, ^then_1, ^else_2
  ^then_1:
    store 2, %0 : i32, i32*
    jump ^merge_3
  ^else_2:
    store 4, %0 : i32, i32*
    jump ^merge_3
  ^merge_3:
    %3 = load %0 : i32* -> i32
    ret %3
}

在程序执行过程，我们可以把这个 if 看成一个分叉点，分叉点之前 a = 1, 而分叉点之后 a = 2 或者 4,可以把这个过程看成有向图。ir 有四个基本块，表达如下：

控制流在 if 出现时发生分叉，在 if 结束时汇合：

我们对其建图，称之为 CFG (Control Flow Graph) 。有了 CFG，就可以将图论的知识应用到程序分析中。支配树就是基于 CFG 构建的。

DomTree

本文涉及到的算法并不仅仅只作用于 DAG，但是为了简单起见，都以 DAG 说明。

首先有存在 DAG 如下：

可以观察到，从节点 1 出发，可以到达其余所有节点，我们给出定义：

钦定入口结点 $s$，对于一个结点 $u$，若从 $s$ 到 $u$ 的每一条路径都经过某一个结点 $v$，那么我们称 $v$ 支配 $u$ ，也称 $v$ 是 $u$ 的一个支配点，记作 $v\ dom\ u$．

对于函数来说，我们一定有一个进入函数执行流的基本块，一定有一个退出函数执行流的基本块，整个过程可以用「存在一个节点 $s$ 可达所有节点的 DAG」建模。如果存在不可达的节点，那么节点无效，可以删除。

接下来我们深入介绍 domtree 相关概念。在图中，节点 1 是所有节点的支配点，而到达节点 6 的路径有两条 $1 \to 2 \to 3 \to 6$ 和 $1 \to 2 \to 3 \to 5 \to 6$ 。则 2,3 是 6 的支配点，而 5 不是 6 的支配点。

把节点 $u$ 所有支配点构成一个集合，称之为支配点集，上图所有节点的支配点集如下：

一个直接的求解支配点思路是，如果一个节点 $u$ 从图中删除导致节点 $v$ 不可达，那么 $u$ 支配 $v$。

显然这个思路可以进行优化，如果已知节点 $u$ 是 $v$ 的支配点，$v$ 是 $n$ 的支配点，则 $u$ 是 $n$ 的支配点。即支配点具有传递性。根据这个性质，我们可以得出对于节点 $u$ 来说，其支配点集就是 $u$ 自身和其前驱接节点的支配点集的交集。在上图中，8 的支配点集就是集合 $\{1,2,3,6\}$ 和集合 $\{1,2,3,5\}$ 的交集和 8 自身 $\{1,2,3,8\}$。

我们把除节点 $u$ 以外的距离 $u$ 最近的支配点 $v$ 称作直接支配点，记作 $v\ idom\ u$。比如节点 8 有支配点集 $\{1, 2, 3, 8\}$，则 3 是 8 的直接支配点，记作 $3\ idom\ 8$ 。除了入口节点 $s$ 以外，其余所有节点都有唯一的直接支配点。若将图中的节点与其直接支配点连边，其构成一颗节点数目为 n 的树，称之为支配树。

这就是我们需要构建的支配树，接下来我们介绍一种快速构建支配树的算法 Lengauer–Tarjan 算法。

Lengauer-Tarjan 算法是构建支配树最有名的算法之一，可以在 $O(n\alpha(n,m))$ 内求出一个有向图的支配树，这个算法最精华的点就是引入了半支配点的概念，将一个全局的复杂问题降级为局部的易分析问题。

如果我们对一个图进行 dfs，所经过的点和边可以构成一颗树。令 $dfn(u)$ 表示为节点 $u$ 被遍历到的时间。这些概念在图论里面很常见（

定义一个集合 $V$ ，其中所有的节点 $v_{i}$ 满足从 $v_{i}$ 出发到节点 $u$，存在一条路径，路径上除了 $u,v_{i}$ 以外，其余所有节点 $x_{i}$ 都有 $dfn(x_{i}) > dfn(u)$。一个节点 $u$ 的半支配点 $v$ 就是集合 $V$ 中 dfn 最小的那个。即 $v = min(V)$。

给出上图的 dfn 序列：

节点 8 的半支配点是 3，其中有节点 6,5,7,3 都满足从自身出发，其路径上除了自身和节点 8，路径上的中间结点的 dfn 序都大于 dfn(8)。而 3 是其中 dfn 最小的一个。

可以观察到，半支配点的产生可能有两种情况，第一种是 $u$ 的直接前驱节点，另一种是如果前驱节点的 dfn 比 $u$ 大，那么就从前驱节点的前驱节点找，这是一个反复执行的过程，直到前驱节点的 dfn 比 $u$ 小。

形式化的说，一个节点 $u$ 的半支配点 $sdom(u)$ 满足：

$$ sdom(u) = min(\{v\ |\ \exists v \to u, dfn(v) < dfn(u)\} \cup \{sdom(w)\ |\ dfn(w) > dfn(u) \text{ and } \exists w \to \dots \to v \to u\}) $$

~~我们不加证明的给出这个公式~~，证明可以参考 oiwiki，并且我们可以用带权并查集维护公式的后半部分。

struct LT_Dsu {
  std::vector<int> father;
  std::vector<int> label; //< label[x] 代表从 x 开始，到并查集中 x 的根节点为止（不包括根节点），其中 dfn(sdom) 最小的节点。
  const std::vector<int> &dfn;
  const std::vector<int> &sdom;

  void find(int x) {
    if (x == father[x]) {
      return;
    }

    find(father[x]);
	
	// 在路径压缩过程中，天然的维护了上述半支配点公式的关系，确保了压缩后可以快速求出 label
    if (dfn[sdom[label[father[x]]]] < dfn[sdom[label[x]]]) {
      label[x] = label[father[x]];
    }

    father[x] = father[father[x]];
  }

  LT_Dsu(int n, const std::vector<int> &_dfn, const std::vector<int> &_sdom)
      : father(n + 1), label(n + 1), dfn(_dfn), sdom(_sdom) {
    std::iota(father.begin(), father.end(), 0);
    std::iota(label.begin(), label.end(), 0);
  }

  int eval(int x) {
    if (x == father[x]) {
      return label[x];
    }

    find(x);
    return label[x];
  }

  // parent node, child node
  void link(int u, int v) { father[v] = u; }
};

那么半支配点有什么用呢？

给出如下算法，记 $x \overset{*}{\to} y$ 表示为 $x$ 是 $y$ 的祖先（可能有 $x = y$），记 $x \overset{+}{\to} y$ 表示 $x$ 是 $y$ 的真祖先（$x \neq y$），对于任何节点 $w \neq s$：

令 $u$ 是 dfs 树路径上 $sdom(w) \overset{+}{\to} u \overset{*}{\to} w$ 上使得 $sdom(u)$ 的 dfn 最小的节点。

$$ idom(w) = \begin{cases} sdom(w) & \text{if } sdom(u) = sdom(w) \\ idom(u) & \text{if } sdom(u) < sdom(w) \end{cases} $$

用普通话说，在 dfs 树上，存在一条路径 $sdom(w) \to x_{0},x_{1},\dots,x_{n}\to w$，路径上除了 $sdom(w)$ 以外的点，构成集合 $X = \{x_{0},x_{1},\dots,x_{n},w\}$，从这个集合选出一个点 $u$，它满足 $\forall x \in X, dfn(sdom(u)) \leq dfn(sdom(x))$。此时 $idom(w)$ 满足上述关系式。

如上图所示，路径 $sdom(8) \to 4 \to 7 \to 8$ 满足上述 $dfn(sdom(x))$ 最小的点是 4 或者 8，满足 $sdom(4) = sdom(8)$，则 $idom(8)$ 就是 3。

在这里再给出一个简单的 case：

考查节点 4，节点 4 的 sdom 是 2，但是 2 不是 4 的 idom。可以观察到路径 $2 \to 3 \to 4$ 中，$sdom(3)$ 小于 $sdom(4)$ ，按照算法更新 4 的 idom 为 $idom(3)$ 也就是 1。

sdom 代表着什么呢？按照我的个人理解，$u$ 的 $sdom(u)$ 代表着从 $sdom(u)$ 出发到 $u$，路径中除去首尾的所有节点都不可能是 $u$ 的 idom，这是一个很强的约束。嗯呢呢，如果把原图 $G$ 中的所有非树边删掉，再对于每个节点 $u$，加上一条由 $sdom(u)$ 到 $u$ 的有向边，那么变化后的新图 $G'$ 和原图 $G$ 的支配树完全相同。也就是说，我们可以假想 $sdom(u)$ 到 $u$ 存在一条直接路径，直接沟通起了 $sdom(u)$ 和 $u$。但这并不意味着 $sdom(u)$ 就一定是 $u$ 的 idom，因为就算中间的所有节点都不是 $u$ 的 idom，但其中某一个节点 $v$ 有可能存在一条 $sdom(v)$ 到 $v$ 的路径绕过 $sdom(u)$。打破 $sdom(u)$ 的支配关系。这个时候就对应上面给出公式的第二种情况。

下给出证明（以下证明的比较 $<,\leq,>,\geq$ 等都表示 dfn 之间的比较）：

首先给出两条引理，引理一（s 是入口节点）：

对于任意 $w \neq s$，直接支配者 $idom(w)$ 必然是半支配者 $sdom(w)$ 的祖先（即 $idom(w) \overset{*}{\to} sdom(w)$）

引理二：

设 $v, w$ 是 DFS 树上的节点且 $v \overset{*}{\to} w$。若树路径 $v \overset{+}{\to} y \overset{*}{\to} w$ 上的每一个节点 $y$ 都满足 $sdom(y) \ge v$，则 $v$ 支配 $w$。

引理都可以使用反证法证明，我就不给出证明了。

首先考虑情况一，假设 $u$ 是树路径 $sdom(w) \overset{+}{\to} u \overset{*}{\to} w$ 上使得 $dfn(sdom(u))$ 最小的节点。

我们有在树路径上 $sdom(w) \overset{+}{\to} y \overset{*}{\to} w$ 的任意节点 $y$ 都满足 $sdom(y) \geq sdom(u) = sdom(w)$，根据引理二，$sdom(w)$ 是 $w$ 的支配点。

既然 $sdom(w)$ 是 $w$ 的一个支配点，根据直接支配点的性质，$idom(w)$ 是最靠近 $w$ 的支配点，$idom(w)$ 必然在 $sdom(w) \to w$ 的路径上，也就是 $sdom(w)$ 是 $idom(w)$ 的祖先，又根据引理一，$idom(w)$ 是 $sdom(w)$ 的祖先，所以 $idom(w) = sdom(w)$。$\blacksquare$

然后是情况二，首先，因为 $sdom(u) < sdom(w)$，这意味着存在一条路径 $sdom(u) \to \dots \to u$ 可以绕过 $sdom(w)$，$sdom(w)$ 就不是 $w$ 的 idom。而因为 $sdom(w) \to w$ 的路径一定经过 $u$，这样构成的相对路径：

$$ idom(u) \overset{+}{\to} sdom(w) \overset{+}{\to} u \overset{*}{\to} w $$

先证 $idom(w)$ 支配 $u$ ，如果 $idom(w)$ 不支配 $u$，则存在一条 $s$ 到 $u$ 避开 $idom(w)$ 的路径，如下：

显然这样出现了一条 $s \to w$ 的路径，与 $idom(w)$ 是 $w$ 的支配点矛盾，所以假设不成立，$idom(w)$ 支配 $u$。进而得到 $idom(w) \overset{*}{\to}idom(u)$。

然后证明 $idom(u)$ 支配 $w$，如果 $idom(u)$ 不支配 $w$，则存在一条从 $s$ 出发避开 $idom(u)$ 到 $w$ 的路径，我们称之为 $p$。

设 $x$ 是路径 $p$ 上最后一个满足 $x < idom(u)$ 的节点（节点 $x$ 一定存在，最起码是 $s$，并且注意这里的 $<$ 是比较的 dfn）。设 $y$ 是路径 $p$ 上最后一个满足 $idom(u) \overset{*}{\to} y \overset{*}{\to} w$ 的节点（节点 $y$ 一定存在，是 $idom(u)$ 的后代，最起码是 $w$）。

考查路径 $p$ 中 $x$ 到 $y$ 这一段子路径，由于 $x$ 的定义，该路径上的内部节点 dfn 不能小于 $idom(u)$，且不能是 $idom(u)$ 的后代。根据 $sdom$ 的定义，有：

$$ sdom(y) \leq x < idom(u) \leq sdom(u) $$

亦即 $sdom(y) < sdom(u)$ !

现在考查 $y$ 的位置，$y$ 不能在 $sdom(w) \overset{+}{\to}z \overset{*}{\to}w$ 上，因为这段路径上，$u$ 的 $sdom$ 最小，如果 $y$ 在这一段，有 $sdom(y) \geq sdom(u)$ 与 $sdom(y) < sdom(u)$ 矛盾。

并且 $y$ 不能在 $idom(u) \overset{+}{\to} z \overset{*}{\to} u$ 上，如果 $y$ 在这里，根据 $sdom(y) < idom(u)$，可以构造出一条等效于 $s \to sdom(y) \to y \to u \to w$ 的路径，并且这个路径不会经过 $idom(u)$，与 $idom(u)$ 是 $u$ 的直接支配点矛盾！所以，$y$ 只能是 $idom(u)$。但是 $y$ 是 $idom(u)$ 并且 $y$ 位于路径 $p$ 上，与假设路径 $p$ 不经过 $idom(u)$ 矛盾，所以 $idom(u)$ 支配 $w$。

所以有 $idom(u) \overset{*}{\to}idom(w)$，根据上面得到的 $idom(w) \overset{*}{\to}idom(u)$，顺利得到 $idom(u)=idom(w)$ 这一结果。$\blacksquare$

综上，证毕。

其实上面的证明也可以这么说，所有从 $s$ 到 $w$ 的路径，都必须经过 $idom(u)$，并且任何比 $idom(u)$ 深的节点，都无法支配 $w$。其实就是证明思路哈哈。

$$ idom(w) = \begin{cases} sdom(w) & \text{if } sdom(u) = sdom(w) \\ idom(u) & \text{if } sdom(u) < sdom(w) \end{cases} $$

根据这个公式和这个公式

$$ sdom(u) = min(\{v\ |\ \exists v \to u, dfn(v) < dfn(u)\} \cup \{sdom(w)\ |\ dfn(w) > dfn(u) \text{ and } \exists w \to \dots \to v \to u\}) $$

我们可以先倒序遍历 dfs 树，求出 sdom 和初步填充 idom，最后再正序遍历把 $sdom(u) < sdom(w)$ 这种情况补上。

为了求出 $v$ 的直接支配者 $idom(v)$，我们必须在 DFS 树路径 $sdom(v) \overset{+}{\to} u \overset{*}{\to} v$ 上寻找一个使 $sdom[u]$ 的 DFN 最小的节点 $u$。

这里存在一个时序冲突，当我们刚求出 $sdom[v]$ 时，逆序 DFN 循环正好执行到节点 $v$。此时，DFS 树路径 $sdom(v) \overset{+}{\to} u \overset{*}{\to} v$ 上的那些中间节点（由于它们是 $v$ 的祖先，DFN 严格小于 $dfn(v)$），还没有被处理，也没有执行过 link 操作。如果此时直接对 $v$ 调用 eval(v)，并查集无法向上检索到 $sdom(v)$，因为那些树边还没有被加入并查集森林。

所以我们得想办法把这个操作延迟进行，如下代码的 bucket 就负责了这个功能：

  void get(int root) {
    dfs(root, root);

    std::iota(sdom.begin(), sdom.end(), 0);

    LT_Dsu dsu(n, dfn, sdom);

    for (int i = timer; i >= 2; --i) {
      int w = vertex[i];

      for (auto &v : preds[w]) {
        int u = dsu.eval(v);

        if (dfn[sdom[u]] < dfn[sdom[w]]) {
          sdom[w] = sdom[u];
        } // 求 sdom
      }

      dsu.link(parent[w], w);

      bucket[sdom[w]].push_back(w);
      int p = parent[w];
		
	  // 延迟更新
      for (auto &u : bucket[p]) {
        int v = dsu.eval(u);
        idom[u] = (dfn[sdom[v]] < dfn[sdom[u]]) ? v : p;
      }
      bucket[p].clear();
    }

	// 正序更新 idom
    for (int i = 2; i <= timer; ++i) {
      int w = vertex[i];
      if (idom[w] != sdom[w]) {
        idom[w] = idom[idom[w]];
      }
    }
  }

下面是例题支配树 Luogu P5180 的代码：

#include <algorithm>
#include <iostream>
#include <map>
#include <numeric>
#include <print>
#include <vector>

struct LT_Dsu {
  std::vector<int> father;
  std::vector<int> label;
  const std::vector<int> &dfn;
  const std::vector<int> &sdom;

  void find(int x) {
    if (x == father[x]) {
      return;
    }

    find(father[x]);

    if (dfn[sdom[label[father[x]]]] < dfn[sdom[label[x]]]) {
      label[x] = label[father[x]];
    }

    father[x] = father[father[x]];
  }

  LT_Dsu(int n, const std::vector<int> &_dfn, const std::vector<int> &_sdom)
      : father(n + 1), label(n + 1), dfn(_dfn), sdom(_sdom) {
    std::iota(father.begin(), father.end(), 0);
    std::iota(label.begin(), label.end(), 0);
  }

  int eval(int x) {
    if (x == father[x]) {
      return label[x];
    }

    find(x);
    return label[x];
  }

  // parent node, child node
  void link(int u, int v) { father[v] = u; }
};

struct DomTree {
  int n;
  std::vector<std::vector<int>> adj;
  std::vector<std::vector<int>> preds;
  std::vector<std::vector<int>> bucket;
  std::vector<int> dfn;
  std::vector<int> vertex;
  std::vector<int> parent;
  std::vector<int> sdom;
  std::vector<int> idom;
  int timer;

  DomTree(int n = 0)
      : n(n), adj(n + 1), preds(n + 1), bucket(n + 1), dfn(n + 1, -1),
        vertex(n + 1, 0), parent(n + 1, 0), sdom(n + 1, 0), idom(n + 1, 0),
        timer(0) {}

  void add_edge(int u, int v) {
    adj[u].push_back(v);
    preds[v].push_back(u);
  }

  void dfs(int u, int p) {
    dfn[u] = ++timer;
    vertex[timer] = u;
    parent[u] = p;

    for (auto &v : adj[u]) {
      if (dfn[v] == -1)
        dfs(v, u);
    }
  }

  void get(int root) {
    dfs(root, root);

    std::iota(sdom.begin(), sdom.end(), 0);

    LT_Dsu dsu(n, dfn, sdom);

    for (int i = timer; i >= 2; --i) {
      int w = vertex[i];

      for (auto &v : preds[w]) {
        int u = dsu.eval(v);

        if (dfn[sdom[u]] < dfn[sdom[w]]) {
          sdom[w] = sdom[u];
        }
      }

      dsu.link(parent[w], w);

      bucket[sdom[w]].push_back(w);
      int p = parent[w];

      for (auto &u : bucket[p]) {
        int v = dsu.eval(u);
        idom[u] = (dfn[sdom[v]] < dfn[sdom[u]]) ? v : p;
      }
      bucket[p].clear();
    }

    for (int i = 2; i <= timer; ++i) {
      int w = vertex[i];
      if (idom[w] != sdom[w]) {
        idom[w] = idom[idom[w]];
      }
    }
  }

  std::vector<int> solve(int root) {
    get(root);

    std::vector<int> ans(n + 1, 1);

    for (int i = timer; i >= 2; --i) {
      int w = vertex[i];
      ans[idom[w]] += ans[w];
    }

    return ans;
  }
};

auto main() -> int {
  int n, m;
  std::cin >> n >> m;

  DomTree solver(n);

  for (int i = 0; i < m; ++i) {
    int u, v;
    std::cin >> u >> v;
    solver.add_edge(u, v);
  }

  auto ans = solver.solve(1);

  for (int i = 1; i <= n; ++i) {
    std::print("{}{}", ans[i], " \n"[i == n]);
  }

  return 0;
}

Dominance Frontier

我们构建支配树的最终目的是提升 ir 至 SSA 形式，亦即插入 $\phi$ 节点。而插入 $\phi$ 节点这一步骤需要借助支配边界，支配边界可以由支配树快速计算得出。

如何插入 $\phi$ 节点和消除 $\phi$ 节点以及如何基于 SSA 优化并不是本文的重点，这里仅仅介绍支配边界（dominance frontier）这一概念。

一个节点 $n$ 的支配边界 $DF(n)$ 是满足如下条件的节点 $m$ 集合：

$n$ 支配 $m$ 的前驱节点。
$n$ 不严格支配 $m$。

很直观对吧（，构建 $DF(n)$ 也很简单，两个 for 循环的事，~~懒得写了~~。

Reference

以及 G 指导的大力支持。

编译优化其一

Sun, 24 May 2026 11:56:38 +0800

HIGH IR

Return Insertion

正如字面意思，这个 pass 很简单，就是给所有没有写上 return 指令的函数补上 return 指令。也不需要考虑很多，看见缺了就填，反正后面会进行的 pass 会消除这个 pass 的副作用。

简单常量传播

在 sysy （c 语言的一个子集）中，store 语句只会在这几种情况下出现：

int a = 1 声明语句
a = 2 赋值语句
void foo(int a) 函数声明

load 语句只会在这几种情况下出现：

int b = a + 1 声明语句
if (a) 条件语句，可以认为循环的 cond 部分也是条件语句
return a 返回语句
foo(a) 函数调用

若在线性顺序下有如下情况：

int a = 1;
int b = a + 1;

a = 2;
int c = a + 1;

foo(a);
if (a) { ... }
// 跨域分析？

我们目前只考虑 i32 和 f32 变量，不考虑数组。

很容易想到，在调用 foo 前的语句，可以把 a 视作常量，这样 b 就可以拿着 a 的值折叠。虽然中间对 a 进行了一次修改，但是我们可以记录这次修改，这样传播到 c 的就是修改后的 a 了。

在线处理，按照顺序扫描，我们依次插入 a，b，c 到「可以进行常量传播的值集合」。

由于 sysy 不允许函数传递指针/引用，函数其实是无法修改外部变量的值的。很容易引申出来：函数前记录下来的「可进行常量传播的值集合」不会被 call 函数指令的副作用改变，所以 call 指令对我们的常量传播没什么影响。更加准确的说，call 指令只会影响全局变量。

进一步，我们只需要注意「可能会修改可以进行常量传播值集合」的指令。在 sysy 中，就是三个指令 call，if，while。

由于在目前阶段还没有进行 mem2reg，进行活跃变量区间分析比较困难，我采取一个很保守的优化原则。遇到 if，while，则清空当前维护的「常量传播值集合」，遇到 call，则清空「常量传播值集合里面的全局变量」。然后对每一个 op 都尝试进行常量传播即可。顺便也把复制传播做了一下。

这样的效果应该还不错，因为声明周期很长的变量远少于声明周期短的 tmp 变量。

简单死代码消除

这个 pass 也比较简单，简述一下流程。

我们维护一个 liveset 和 worklist。首先标记出不能删除的指令加入到 worklist，他们有：

外部链接函数
store 指令
ret 指令
控制流终结符

然后进行反向传播（倒序遍历），如果一个指令处于 worklist，那么他自身和其引用的指令也要加入到 liveset 和 worklist，如果一个 if/while 内部有指令在 liveset 中，那么保守起见，整个 if/while 都加入到 liveset 中。反向传播完毕后，就可以清除所有不属于 liveset 中的指令了。~~这就是 bfs 吧~~

Inline 优化

Inline 其实是一个非常复杂的优化，在什么时候应该 inline，这是一个 NP hard 的问题，一个函数是否应该 inline，我们需要几个标准来权衡：

inline 前后是否有性能提升。
在上面这一点，就算 inline 没有显示的性能提升，如果在 inline 后，能够进行更多 pass 来优化，导致最终结果比 inline 前好。
我们是否能够承担 inline 带来的副作用，比如栈开销。
inline 会导致代码体积变大。
…

不仅仅有上面列出的点，我们还要考虑什么时候进行 inline，以什么顺序，付出多少代价等等。。。是一个非常复杂的问题。

由于其是一个 NP hard 的问题，我们很难找到一个多项式时间内处理 inline 的算法，通常我们基于启发式算法来处理 inline。

所以呢，我从 llvm 剽窃偷学了他们的启发式算法（阉割版）。接下来要做非常复杂的算法了哦~嘿嘿嘿嘿

参考论文：http://impact.crhc.illinois.edu/shared/papers/p246-chang.pdf

描述一下宏观流程：

构建加权调用图
强连通分量分解
内联决策
代码转化

思路是这样的，代码的遍历流程天然和图相符，我们采用图来建模是很自然的想法：将函数视为节点，每个 call 指令视为弧，就能构建出一个有向图。

这样建模的话，我们可以很轻松的发现递归函数：一个环。在有向图中，环的存在很不好处理，所以我们进行 SCC 缩点，也就是 tarjan 算法。缩点后再跑一遍拓扑排序即可。在 topo 过程中，我们对每个 call 指令计算 cost，再设置一个阈值（threshold），与 cost 比较，来判断是否应该内联，最终依据结果进行内联。内联后再跑一遍 CP 和 DCE。

思路很简单，难的是如何计算 cost。inline 的 cost 的时刻在变化的，并且他的阈值也不同，举个例子，一个在 while 里面被调用的函数 inline 的性价比明显比在 while 外面的函数 inline 高。为了权衡这些复杂的情况，我们的 cost 的计算也必须是动态的。

按照 LLVM 的 cost 体系，基础指令/内存访问的 cost 为 5，跳转/分支的 cost 为 10，函数调用的 cost 为 25，昂贵运算 mul/div 等在 10-20 左右，全零初始化的 cost 是 0。

然后是奖励分，如果能够 SRAO 优化，则减 15-20。如果能够常量折叠，将指令 cost 变为 0（这个很重要，比如一个递归的斐波那契函数 fib(12)，可以不断 inline，常量传播，最终优化成一个具体的数值）。

我们的初始阈值设为 225，在一定的情况下，我们会对阈值进行调整，比如说在 while 里面的函数，我们采用 $T_{final} = T_{base} + (depth \times 150)$ 公式 scale up。如果在一个经常为 false 的语句，比如 if (bad situation) { call function; break; } 这种我们就要降低其阈值（$\div 10$），因为这种内联反而没那么划算。

最终我们依据 cost < threshold 的结果来判断是否内联。当然存在一些特殊情况，有些很小的函数（指令数 < 10），简单函数包装（包装另一个函数返回结果）我们可以直接内联。还有我们得考虑函数的栈开销，如果全部 inline 了导致爆栈可不太好。

编译原理完结篇

Tue, 24 Feb 2026 13:12:21 +0800

稍微填一下坑，最近重新写了一遍，感悟又有所不同。

~~啊嘞啊嘞嘞，怎么直接从准备到完结了~~

按照教程的顺序，应该是先写前端解析出 AST 然后再遍历出 koopa ir 最后进行代码生成。流程很短，事实上少了优化的过程，确实非常简单。

在函数之前的内容就不赘述了，教程写的很完善，实际也不难。由于不需要考虑浮点数和整数之间的转换，中期的短路求值其实很好写，写一个 if-else 就解决了。

在写 while 和 if 时，需要注意处理 break 和 continue 语句，我们可以根据代码的层级嵌套关系，使用栈来维护一个 scope 栈来管理基本块，进入 basic block 就 push 进去，离开 bb 就 pop。在 sysy 中，只有这四种情况会产生 scope：

function 内部是一个 scope
if 内部是一个 scope，else 内部是一个基本块
while 内部是一个 scope
空的 {} 是一个 scope

我们在全局用一个栈来维护这种 scope 之间的嵌套关系，然后再 visit scope 内部的基本块，比直接在基本块中处理 break 和 continue 要好些的多。~~可能说的比较抽象~~。

在写函数和全局变量时，教程中介绍了寄存器分配：完全不分配。这个部分比较有意思，可以看看 R 大的回答：https://www.zhihu.com/question/29355187/answer/51935409

工业上一般采用改进后的线性扫描算法，比如 llvm 就是基于变量权重使用优先队列来进行遍历的。

在我体感中，数组的初始化和访问是教程中最复杂的部分。sysy 数组的初始化和 c 标准相同。

由于教程中写的不是很详细，我想仔细讲讲这个部分。

举个例子，这个初始化 int a[2][2] = {1, {1, 2}} 是正确的吗？

这个 int a[2][2] = {{1}, {1, 2}} 呢？

下面这个更加复杂的呢？

int arr[2][3][4] = {
        {1, 2, 3, 4},
        {5}, 
        {6},
    {
	    {1, 2, 3, 4},
        {1, 2, 3, 4}, 
        {1, 2, 3, 4} 
    }
};

以及教程中这个 int arr[2][3][4] = {1, 2, 3, 4, {5}, {6}, {7, 8}}; 例子呢？

一步一步来，事实上，一个 {} 就对应一个数组：int a[2] = {1, 2}; 中，{} 对应 int[]；int a[2] = {{1, 2}, {1, 2}}; 中，最外面的 {} 对应着 int[][]，里面的 {} 对应着 int[]。

一个好的数组初始化，它 {} 的嵌套关系和数组维度应该是严格对应的。但数组初始化没有这么简单。如果我没有写 {} 呢？多写了一个 {} 呢，又或者我没有填充满呢？

但事实上，c 标准没有严格要求一一对应，比如 int x = {4}; 是正常写法，可以编译通过的，这就引申出一条非常重要的规则：「当 {} 高于当前对应的数组维度时，把这个大括号当作对当前单个标量的初始化」。也就是说，int x = {4} 和正常的 int x = 4; 没有区别，但是 int x = {1, 2}; 就不被允许。int x = {{4}} 也不行，因为外面的 {} 对齐到了标量，内部的 {4} 完全没有坑给他。

而另一方面，如果我少写了 {}，比如 int x[2][2] = {1, 2, 3, 4}，他也会正确初始化成 int x[2][2] = {{1, 2}, {3, 4}}。这个规则可以总结成为：「如果缺少大括号，会按照平坦的内存顺序，从 [0][0] 开始填充」。

这个例子则可以说明缺少 {} 时的另一个规则 int x[2][2] = {1, 2, {3, 4}}。「当遇到一个左大括号时，编译器会贪心的将这个子数组内容对齐到当前维度下最适合的子维度」。结合上面刚提到的规则，1, 2 填充给了 [0][0] 和 [0][1]。{3, 4} 则刚好适合 x[1]。

这两个规则同样也可以解释这个例子 int a[2][3][4] = {1, 2, 3, 4, {5}}。1, 2, 3, 4 刚好填充 int a[0][0]。这时的 {5} 则适合对应 int a[0][1]。最终结果就是 int a[2][3][4] = {{{1, 2, 3, 4}, {5, 0, 0, 0}, ...}, ...}。

这个例子则很好的结合了前面提到的所有规则 int x[2][2] = {1, {1, 2}}。首先 1 会被填充到 [0][0] 位置处，然后遇到了一个 {。现在的问题是，由于只填充了 [0][0], {1, 2} 没有办法给 x[1]，只能给 x[0][1]。则就是前面提到过的 int a = {1, 2} 的错误。这个初始化是不正确的。而 int x[2][2] = {1, {5}, {1, 2}} 则是正确的。

到了这里，很多东西都能解释的比较通顺了，但你可能会产生疑问 int x[2][2] = {1, {1, 2}} 为什么不能解释成 int x[2][2] = {{1, 0}, {1, 2}} 呢？这就要揭示我们之前隐含的一个东西，我们实际上是在维护一个指针从头开始扫的，这个指针在的维度就是 {} 要贪心填充的维度的父维度。同样是这个例子 int x[2][2] = {1, {1, 2}}。我们是维护一个指针 p 填充，当 1 填充给了 [0][0] 后，这个指针是指向 [0][1] 的，所以 {1, 2} 只能填充给 [0][1]。而这个例子中 int a[2][3][4] = {1, 2, 3, 4, {5}} 中，填充完 1, 2, 3, 4 后，指针是在 [0][1] 这里的，所以 {5} 才能填充给 [0][1]。

当然，还有一个补零的规则我没有说，但这个其实很显然的。总结一下，我们总共有四条规则：

线性填充，如果你不使用内部的大括号，那么会按照平坦的顺序从 [0][0][0] 开始填充。
子对象对齐，当遇到一个左大括号 { 时，他会尝试将这个 { 对应的数组填充到当前指针指向的位置。如果当前指针恰好是一个数组的开头位置（对齐），那么这个 { 就负责初始化这整个子数组，如果不是，则是下面的规则。填充这个子数组的规则同样是这四条。
标量括号限制，当你在非对齐的位置遇到了左大括号 {，他不能把这个 { 给子数组，因为没有对齐。他只能把这个 { 给到当前的标量 int/float。
自动补零，只要当前的数组被部分初始化了，所有未显示指定的元素都会被初始化成 0

emmm，就是这样，也许我讲的不是很清楚，~~我自认为还算清楚~~。写法是一个递归的过程，过程就和我叙述的一样，当然有一些细节需要处理。

好啦，最难的部分就是这样，如果你还想继续研究编译器，可以看看 MaxXing 后面的进阶篇。当然，那些内容还不足以说明编译器的广度和深度，但也是一个很好的入门部分呢。

编译原理准备篇

Wed, 17 Dec 2025 13:57:23 +0800

Docker

maxXing 提供为实验提供了 docker 镜像，所以我们只需要将 docker 下载下来拉取镜像即可。

使用 pacman 下载 docker：

`1`	`sudo pacman -S docker`

关于如何使用基本的 docker 文档里面有足够的讲解，在此不再赘述。

主要来讲解一下引入 docker 导致宿主机的环境问题。

首先 docker 默认会以 sudo 运行，这涉及到一些历史遗留问题。但客观事实是，这不合常理。所幸，docker 可以通过配置来解决这个问题：

1
2

# 可以将 `docker` 添加进用户组避免 `sudo`。
sudo usermod -aG docker $USER

其次，docker 会改变修改默认的 IP 转发：

sudo iptables -nvL FORWARD
[sudo] password for anfsity:
Chain FORWARD (policy DROP 1735 packets, 177K bytes)
 pkts bytes target     prot opt in     out     source               destination
 1735  177K DOCKER-USER  all  --  *      *       0.0.0.0/0            0.0.0.0/0
 1735  177K DOCKER-FORWARD  all  --  *      *       0.0.0.0/0            0.0.0.0/0

可以看到，docker 将策略改成了 DROP …

如果你之前有跑在宿主机上的类似容器应用，就需要将对应的端口开放给 iptables。

Article

关于 docker 的流量转发我没有做过多的了解，可以看官方文档自行了解。

Networking overview

Packet filtering and firewalls

配置 `clangd`

如果你使用 c++ 进行 Lab 的话，可能你像我一样使用 clangd 。

但是由于每次运行都是在 docker 里面进行的，这就造成一个问题–如果你使用 cmake 来自动生成 cdb 文件的话，它的路径是 docker 里面的路径而不是宿主机里的路径。

这就导致了 clangd 找不到对应的 cdb ，然后就框框爆红 **file not found 。

这让我很是头疼，网上搜寻了一番，大致有两种思路：

在 docker 里面也装一个 clangd ，然后把 docker 里面的 clangd 通信转发到 vscode 里面来。

这个策略有很多不足，一是折腾起来麻烦；二是就算弄好了 clangd 也没有办法享受我宿主机上的 zsh 环境；三是这只适用于 vscode ，如果我用其他的 IDE 那又要折腾一番了。

把宿主机的目录挂载到 docker 上来，让 docker 的路径和宿主机相同。

这个思路我是在一篇 reddit 的讨论帖上看到的，感觉不错，遂剽窃使用。

为了发扬懒人精神，我把这些命令整合到了 Makefile 中。

我只会 Makefile QAQ，而且它也足够简单(简单吗…?)，只要不写太多东西。犹记得初见 Makefile 时的语法，神似鬼画符🤔

IMAGE = maxxing/compiler-dev
BUILD_DIR = cmake-build

UID := $(shell id -u)
GID := $(shell id -g)
PWD := $(shell pwd)

all: build

configure:
	cmake -S . -B $(BUILD_DIR)

build: configure
	cmake --build $(BUILD_DIR) -j12

clean:
	rm -rf $(BUILD_DIR)

shell:
	docker run -it --rm \
			-u $(UID):$(GID) \
			-v "$(PWD):$(PWD)" \
			-w "$(PWD)" \
			$(IMAGE) bash

docker-build:
	docker run --rm \
		-u $(UID):$(GID) \
		-v "$(PWD):$(PWD)" \
		-w "$(PWD)" \
		$(IMAGE) \
		sh -c "cmake -S . -B $(BUILD_DIR) && cmake --build $(BUILD_DIR) -j12"

你可以在根目录下 make shell 直接进入 docker，make 进行编译。

由于是在 user 模式进入的 docker, 你无法使用 sudo, 这意味着，你没有办法使用此类需要 root 权限的指令 sudo apt update && sudo apt install ***。

同时需要注意的是，我个人习惯的构建目录是 cmake-build 而不是 build。

在我对编译器进行了模块化改造后，就是使用的第一种方法，这种方法可以使用 devconatiner 插件简单的实现。这是我的 json 配置，你可以参考它。

好消息是我为上游推送了 clangd 支持，到时候 docker 应该内置 clangd，不过上面的内容依然适用。

CMake

谈到 CMake ，只能说又爱又恨。众所周知，C++ 没有像 rs，py 那样好用的包管理器，目前流行的包管理器各有各的缺陷。

不过包管理器相关的知识太过庞杂，而且我也并不熟悉，就不在这里展开叙述了。

我们来魔改一下 maxXing 的 CMakelists 👍

按照现代 CMake 的思想，一切皆为 target 和模块化，我们来调整一下 CMakelists。

~ anfsity  main  zsh
 tree -d
.
├── debug
├── include
│   ├── backend
│   └── ir
├── scripts
├── src
│   ├── backend
│   ├── frontend
│   └── ir
└── tests

11 directories

我们在顶层目录和 src/include 目录都放一个 CMakelists 来管理。

这是我学习 Cmake 的入门视频。

# root CMakelists.txt
cmake_minimum_required(VERSION 3.20)

project(
    compiler
    LANGUAGES CXX
    DESCRIPTION "PKU Compile Principle LABs."
    VERSION 0.1.0
)

# c++ settings
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

# binary_dir : the output dir like build/cmake-build
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})

# library fmt
include(FetchContent)
FetchContent_Declare(
    fmt
    GIT_REPOSITORY https://github.com/fmtlib/fmt.git
    GIT_TAG         12.1.0
)
FetchContent_MakeAvailable(fmt)

# Flex & Bsion
find_package(FLEX REQUIRED)
find_package(BISON REQUIRED)

add_subdirectory(include)
add_subdirectory(src)

enable_testing()

file(GLOB_RECURSE test_cases "tests/*.c")

foreach(test_file ${test_cases})
    get_filename_component(test_name ${test_file} NAME_WE)
    get_filename_component(parent_dir ${test_file} DIRECTORY)
    get_filename_component(group_name ${parent_dir} NAME)
    add_test(
        NAME ${group_name}/${test_name}
        COMMAND python3 ${CMAKE_SOURCE_DIR}/scripts/test_runner.py
                $<TARGET_FILE:compiler>
                ${test_file}
    )
endforeach()

看了一下 docker 里面的环境配置：

Tool	Version	Status/Notes
CMake	3.28.3	现代版本，但离目前的 head 还是稍旧。
Python3	3.12.3	最新的稳定版本之一。
Rust Toolchain (Cargo)	1.91.1	版本非常新 (构建日期 2025-10-10)，处于前沿。
flex	2.6.4	标准版本。
bison	3.8.2	标准版本 (GNU Bison)。
GCC	13.3.0	构建于 Ubuntu 24.04。支持 C++20 标准。
Clang	21.1.6	版本极新。但是可能由于 libc++ 限制，可能无法使用 std::print 。
LLVM	21.1.6	Clang 的底层框架，版本与 Clang 一致。

环境可以说是非常现代，但是很遗憾无法使用 print 库。

我早受够用 cout 的 <</>> 来输出字符串了，真的很难用，便把 print 的原型库 fmt 拉过来使用。

没想到 fmt 比 print 还好用。

我的实现有一个缺陷，为了避免引入依赖，我直接使用 cmake 拉取 fmt 仓库。这导致每次测试的时候都要进行一次拉取。如果网络好的时候还算顺畅，但是校园网时常抽风，偶尔要等待半天。

不过也可以指定输出目录进行增量编译，这也不算是什么大问题了。

# src/CMakelists.txt
# generate lexer/parser
set(LEXER_SRC frontend/sysy.lx)
set(YACC_SRC frontend/sysy.y)

# generate the lexer and parser files
flex_target(Lexer ${LEXER_SRC} ${CMAKE_CURRENT_BINARY_DIR}/sysy.lex.cpp)
bison_target(Parser ${YACC_SRC} ${CMAKE_CURRENT_BINARY_DIR}/sysy.tab.cpp)
add_flex_bison_dependency(Lexer Parser)
message(STATUS "[INFO]  Generated lexer: ${CMAKE_CURRENT_BINARY_DIR}/sysy.lex.cpp")
message(STATUS "[INFO]  Generated parser: ${CMAKE_CURRENT_BINARY_DIR}/sysy.tab.cpp")
message(STATUS "[INFO]  Generated lexer outpus ${FLEX_Lexer_OUTPUTS}")
message(STATUS "[INFO]  Generated parser outpus ${BISON_Parser_OUTPUT_SOURCE}")

set(CORE_SOURCES
    ir/ast.cpp
    backend/backend.cpp
    ${FLEX_Lexer_OUTPUTS}
    ${BISON_Parser_OUTPUT_SOURCE}
)

add_library(compiler_core STATIC ${CORE_SOURCES})

target_include_directories(compiler_core PRIVATE
    ${CMAKE_CURRENT_BINARY_DIR}  # cmake-build/src/* for generated lexer/parser
)

# compiler core link libraries
target_link_libraries(compiler_core PUBLIC
    koopa
    pthread
    dl
    fmt::fmt
    headers
)

# complie options
target_compile_options(compiler_core PRIVATE -O2 -Wall -Wno-register -Wextra)

# executable
add_executable(compiler main.cpp)
target_compile_options(compiler PRIVATE -O2 -Wall -Wno-register -Wextra)
target_include_directories(compiler PRIVATE $ENV{CDE_INCLUDE_PATH})

# compiler link libraries
target_link_libraries(compiler PRIVATE compiler_core)
target_link_directories(compiler PRIVATE $ENV{CDE_LIBRARY_PATH}/native)

# include/CMakeLists.txt
add_library(headers INTERFACE)

target_include_directories(headers INTERFACE
    # include/
    ${CMAKE_CURRENT_SOURCE_DIR}
)

message(STATUS "[INFO]  Compiler Headers Target created: headers")

这是我最终的目录结构，~~测试还没写完~~，从别处剽窃了一些测试过来。

 tree
.
├── CMakeLists.txt
├── debug
│   ├── hello.asm
│   ├── hello.koopa
│   └── test_temp
│       └── **
├── include
│   ├── backend
│   │   ├── backend.hpp
│   │   └── koopawrapper.hpp
│   ├── CMakeLists.txt
│   ├── ir
│   │   ├── ast.hpp
│   │   ├── ir_builder.hpp
│   │   ├── symbol_table.hpp
│   │   └── type.hpp
│   ├── koopa.h
│   └── Log
│       └── log.hpp
├── Makefile
├── scripts
│   └── test_runner.py
├── src
│   ├── backend
│   │   └── backend.cpp
│   ├── CMakeLists.txt
│   ├── frontend
│   │   ├── sysy.lx
│   │   └── sysy.y
│   ├── ir
│   │   ├── ast.cpp
│   │   └── codegen.cpp
│   └── main.cpp
└── tests
    ├── hello.c
    └── resources
        ├── functional
        │   └── **
        └── hidden_functional
            └── **

16 directories, 620 files

如果你想使用这个 CMake 文件，你必须严格遵循我的目录结构，并且把对应的 CMake 文件放到正确的位置，如果你对 CMake 不了解的话，还是使用课程提供的模板文件比较好。权当我为你提供了一种 CMake 参考配置。

这个配置是使用了 module 之前的配置，当前仓库的配置是适配了 module 之后的配置。

模块

什么？都 2026 了，我们还在使用传统 cpp 的 pch Σ(ﾟ∀ﾟﾉ)ﾉ

modules 现在处于一个很尴尬的处境，大家都夸他，但是没人用。

模块的好处及用法可以参见这篇文章 C++20 Modules 用户视角下的最佳实践。

经过亲身体验后，我建议这个还是不要碰的好，因为弄好环境其实挺麻烦的。如果一定要引入的话，最好从一开始就原生支持，并且需要修改 CMake 文件。

CMake 进行模块构建目前好像只能使用 ninja （还有谁我忘了），所以你还需要配置 ninja。

你可以使用我的 devcontainer 配置，相关环境都已经弄好了 devcontainer.json 。

怎么用就自行询问 AI 吧。

简单的日志打印

一个小巧且漂亮的日志打印可以很好的帮助你进行 debug，在 cpp 20 （还是 23 ？我忘了）引进了 source_location，它可以很好的取代部分宏调试的功能，使用起来更加方便和舒适。

fmt 库的强大功能中包含了颜色调节，这是标准库还没有实现的功能。fmt 看起来比较麻烦，但用起来意外的舒服，很符合“人体工学”。

/**
 * @file log.hpp
 * @brief Logging and error handling utilities for the compiler.
 */
#pragma once

#include <fmt/color.h>
#include <fmt/core.h>
#include <source_location>
#include <string>

namespace detail {

/**
 * @brief Formats a message with source location information.
 * @param loc The source location.
 * @param fmt_str Format string.
 * @param args Format arguments.
 * @return Formatted string including location info.
 */
template <typename... Args>
static auto format_msg(const std::source_location &loc,
                       std::string_view fmt_str, Args &&...args)
    -> std::string {
  std::string user_msg =
      fmt::format(fmt::runtime(fmt_str), std::forward<Args>(args)...);

  return fmt::format(fmt::fg(fmt::color::alice_blue), "{} (at {}:{} in {})", user_msg, loc.file_name(),
                     loc.line(), loc.function_name());
}

/**
 * @brief Custom exception for compilation errors.
 */
class CompileError : public std::runtime_error {
public:
  explicit CompileError(const std::string &message)
      : std::runtime_error(message) {}
};

} // namespace detail

/**
 * @brief Static logging utility.
 */
class Log {
public:
  /**
   * @brief Reports a fatal error, prints debug info, and throws a CompileError.
   *
   * @param fmt_str Format string for the error message.
   * @param args Arguments for the format string.
   * @param loc Source location (defaults to caller site).
   */
  template <typename... Args>
  static auto
  panic(std::string_view fmt_str, Args &&...args,
        const std::source_location &loc = std::source_location::current())
      -> void {
    fmt::print(stderr, fmt::emphasis::bold | fmt::fg(fmt::color::red),
               "[PANIC] ");
    std::string msg =
        fmt::format(fmt::runtime(fmt_str), std::forward<Args>(args)...);
    fmt::println(stderr, "{}", msg);
    fmt::print(stderr, fmt::fg(fmt::color::slate_gray), " --> {}:{}:{}\n",
               loc.file_name(), loc.line(), loc.function_name());

    throw detail::CompileError(
        detail::format_msg(loc, fmt_str, std::forward<Args>(args)...));
  }

  /**
   * @brief Prints a trace message for debugging.
   *
   * @param fmt_str Format string for the trace message.
   * @param args Arguments for the format string.
   * @param loc Source location (defaults to caller site).
   */
  template <typename... Args>
  static auto
  trace(std::string_view fmt_str, Args &&...args,
        const std::source_location &loc = std::source_location::current())
      -> void {
    fmt::print(stdout, fmt::fg(fmt::color::cyan), "[TRACE] ");
    fmt::print(stdout, "{} ",
               fmt::format(fmt::runtime(fmt_str), std::forward<Args>(args)...));
    fmt::print(stdout, fmt::fg(fmt::color::dark_violet), "[{}]\n",
               loc.function_name());
  }
};

代码风格

代码风格可以参考 llvm 和 google 的 style 手册，应该在网上一搜就有。

或者可以使用 clang-format 一键格式化，clangd 会包含它。

对于某某特性应不应该使用的问题，我觉得只要你在项目保持前后一致性，就没什么问题。由于是 toy project，~~我会把语言特性拉的尽可能的新~~。

代码注释

尽可能的写注释……且要写明白…..否则你就会像我一样，一个星期不看就看不懂要重新把所有源码再看一遍…

为什么会一两个星期没看呢，因为要期末考试…

Anyway，就算不是因为这个原因，良好风格的注释在项目中也是非常重要的，

我目前的观点是，好的代码应该做到：代码即注释。但是对于复杂的逻辑，以及一些危险的操作，需要用注释来补全。

内存管理

为了支持 RAII，我个人的做法是把所有的函数和过程都用类包装起来了，为了兼容 bison 还写了一套构造函数用于从裸指针构造。

简单举个例子：

/**
 * @brief Left-value expression (variable / array access).
 */
LVal
  : IDENT {
    $$ = new LValAST(std::move(*$1), {});
    delete $1;
  }
  | IDENT ArraySuffix {
    $$ = new LValAST(std::move(*$1), std::move(*$2));
    delete $1;
    delete $2;
  };

class LValAST : public ExprAST {
public:
  std::string ident;
  std::vector<std::unique_ptr<ExprAST>> indices;
  /**
   * @brief Constructs an LVal node.
   * @param _ident The variable name.
   */
  LValAST(std::string _ident, std::vector<std::unique_ptr<ExprAST>> _indices)
      : ident(std::move(_ident)), indices(std::move(_indices)) {};
  auto dump(int depth) const -> void override;
  auto codeGen(ir::KoopaBuilder &builder) const -> std::string override;
  auto CalcValue(ir::KoopaBuilder &builder) const -> int override;
};

Compile Principle

Tue, 02 Dec 2025 18:23:54 +0800

思来想去，还是在 CS143 和 pku 的编译原理之间选择了 pku 的，顺便再看看 LLVM 的 Kaleidoscope 。

CS143 是经典课程，但是 pku 的 lab 又足够诱人，它给予了你高度的自由从头来设计一个编译器。

虽然说是从头，但其实大体的框架限制的比较死，如果真的要从头写一个，那恐怕花费的时间就不是这一个课程能够容纳的了。

前端基本上是交给 yacc & bison，所要做的事仅仅是解析正则和生成 ir，并不需要亲自动手实现文法解析。而遍历 ir 的部分也由 maxXing 写好了，只需要借助相关设施生成的对象写完剩余的 rsicv 生成即可。

不过虽说做了些简化工作，但是实际动手起来还是很费时。~~最好的建议是照抄 llvm~~

写了一些笔记：

编译原理准备篇

编译原理完结篇

差不多两个月的时间，如果除去中间因为期末考试和放寒假玩了一个星期导致的真空期，剩下的差不多一个月出头，比我想象的其实要快很多。大抵是搓编译器太有意思了。

写点感想。这个 lab 是极好的，真好国内有这么高质量的课程。美中不足的是，引导稍微有点不够。但总的来说，课程的开放保持的恰到好处，给予你足够的思索空间，既不像傻子一样全部一步一步的告诉你，也不像某些天书一样不说人话。

感谢 maxXing 创作了质量如此之高的教程。

$upd$:

libkoopa 有文档了 (笑)