本节内容接上。。源码解读—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