源码解读---mem2reg源码（2）

本节内容接上。。源码解读—mem2reg源码（1）

上文说到，我们已经计算出了每个alloca变量（这里指的是，LLVM给每个函数中的局部变量创建了 一个alloca指令，模拟其分配在栈上的行为。），接下来我们就要计算我们的PHI节点在哪插入的问题了。

在回答这个问题之前，首先推荐大家去看下 《Engineering a Compiler》对应的章节。其实，我们可以发现，PHI节点的插入不是随意的，随意的插入可能会导致程序语义的错误以及冗余的PHI节点带来的是指令冗余开销。所以，正确的插入方式是插入到某些BB（基本块）的支配边界BB的开头。

在继续往下读直接，大家可以先阅读下面的资料：
构造Dominator Tree以及Dominator Frontier
再谈Dominator Tree的计算
以及《Engineering a Compiler》对应的章节

朴素的计算支配边界的算法复杂度很高，可以达到O(N^4)级别，这样一个复杂度对大型程序来说，是不现实的。那么有没有一种方法能够达到更低的复杂度呢？

下面介绍一篇LLVM至今仍使用的算法，即IDF（iterated Dominator Frontier），它的复杂度为O(N)，基本上从复杂度的量级来看，是目前最好的。论文地址：A Linear Time Algorithm for Placing PHI-Nodes

这里简单阐述下这篇论文的几个观点以及算法。感兴趣的可以详细去看。

作者对支配边界计算的主要优化点在于支配者树，与传统的支配者树相比，作者添加了J-Edge。而传统的支配者树的边叫做D-Edge。这样所构成的图叫做DJ-graph。那么，作者为什么要这么干呢？

我们知道，如果要计算一个基本块A的支配边界，传统的方法是要去遍历基本块A的所有前驱，然后把不是直接支配的前驱加入到支配边界中。乍一看，好像复杂度也不高，但是注意了，这里只是对某一个基本块来说的，如果我要找到多个基本块组成的集合的边界怎么办？那么我们都会按照上面的方法操作一次，这样就带来一个问题，某些基本块可能会重复计算。看到这里，有些人会想到动态规划，即我用一个缓存来存不就行了吗？其实这样的空间复杂度也挺高的。

也有的同学说，我自下而上，先计算子节点，再利用子节点的边界计算父节点不就行了吗？对，这个思想就是这篇论文的思想。除此之外，作者还做了一些优化，给支配者树每一层编上号，然后利用支配边界节点的序号不大于（可以等于）根节点（要获取支配边界的那个节点），就可以计算出来边界节点，而不需要去遍历了。 为什么有这个特性，感兴趣可以去看下论文作者写的另一篇论文，有详细介绍。这里不展开了。

下面看个例子：

Figure 1中左边是CFG，右边是根据左边得到的传统的支配者树。然后我们给他加J-Edge。讲到这里，为什么作者需要加J-Edge呢？其实就是为了减少计算量，边界节点一定是J-Edge上的几点。因为D-Edge连接的是直接支配节点，是严格支配的。

文中对J-edge的定义如下：

Definition 3.1 (J-edge) An edge x -> y in a flowgraph is named a join edge
(or J-edge) if x !sdom y. Furthermore, y is named a join node.

意思是说，如果流图中，x不严格支配y，则x->y就是J-edge。

生成的最终的DJ-graph如下图：

论文有个引理：

论文的主要核心就是这个引理。

后面就是求解放置PHI节点的算法了，算法比较长，大家自己去看下。伪代码很简单，一看就懂。

回到LLVM中，我们来看下LLVM是如何放置PHI节点的。

 // At this point, we're committed to promoting the alloca using IDF's, and
    // the standard SSA construction algorithm.  Determine which blocks need phi
    // nodes and see if we can optimize out some work by avoiding insertion of
    // dead phi nodes.
    IDF.setLiveInBlocks(LiveInBlocks);
    IDF.setDefiningBlocks(DefBlocks);
    SmallVector<BasicBlock *, 32> PHIBlocks;
    IDF.calculate(PHIBlocks);
    llvm::sort(PHIBlocks, [this