Incremental Computation of Dominator Trees

Transcription

1 Incremental Computation of Dominator Trees Vugranam C. Sreedhar Guang R. Gao ACAPS Laboratory School of Computer Science McGill niversity, CANADA Yong-fong Lee Application Development Technology Institute IBM Software Solutions Division San Jose, California Abstract Data flow analysis based on an incremental approach may require that the dominator tree be correctly maintained at all times [CR88]. Previous solutions to the problem of incrementally maintaining dominator trees were restricted to reducible flowgraphs [RR94, CR88]. In this paper we present a new algorithm for incrementally maintaining the dominator tree of an arbitrary flowgraph, either reducible or irreducible, based on a program representation called the DJ-graph [SG95, SGL94a]. For the case where an edge is inserted, our algorithm is also faster than previous approaches (in the worst case. For the deletion case, our algorithm is likely to run fast on the average cases. Introduction In the past few years, Static Single Assignment (SSA form [CFR 89, CFR 9], Sparse Evaluation Graphs (SEG [CCF9], and other related intermediate representations have been successfully used for efficient data flow analysis and program transformations [CLZ86, RWZ88, AWZ88, WZ85, WCES94]. Construction of these intermediate representations needs to first compute the dominance relation of a flowgraph. An inherent difficulty in aggressive program optimizations based on SSA is maintaining the correct SSA form after every program transformation. To achieve this one must correctly maintain the dominator tree of the flowgraph. In this paper we present a new algorithmic framework for incrementally maintaining the dominator tree of an arbitrary Copyright c 995 by the Association for Computing Machinery, Inc. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or direct commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept., ACM Inc., fax + ( , or (permissions@acm.org. IR 95, /95, pp -2, San Francisco, California, SA c 995 ACM flowgraph. For this problem previous work most relevant to this paper includes only the Carroll-Ryder algorithm [CR88] and the Ramalingam-Reps algorithm [RR94]. Both methods are restricted to reducible flowgraphs. By contrast, our approach can handle irreducible as well as reducible flowgraphs. Our algorithms only performs updates based on the nodes which are affected by the corresponding insertion or deletion of an edge (thus reducing the total cost; furthermore, the properties of DJ-graphs are used to efficiently identify these affected nodes. For the case where an edge is inserted, our algorithm has an time complexity, where is the number of edges in the flowgraph better than previous approaches [CR88, RR94]. For the deletion case, our new incremental algorithm is also competitive in terms of running time. It is expected to run faster on the average cases while not compromising its worstcase time complexity. To incrementally maintain a dominator tree, we use properties of DJ-graphs [SG95, SGL94a] and iterated dominance frontiers [CFR 9]. A DJ-graph is nothing but a dominator tree augmented with join edges that potentially lead to merge points in the corresponding flowgraph. In a flowgraph, an edge is a join edge if does not strictly dominate. DJ-graphs allow us to solve a number of flowgraph problems [SGL94a, SG95]. In particular, it enables us to design an algorithm for computing - nodes for an arbitrary Sparse Evaluation Graph (SEG in linear time and space [SG95]. In this paper, we go one step further and show how to update a DJ-graph in response to changes made in the corresponding flowgraph. Since DJ-graphs are dominator trees augmented with join edges, the problem of updating DJ-graphs subsumes the problem of updating dominator trees. We are currently implementing a complete framework based on DJ-graphs for performing sparse and incremental analysis, including dominator updates. Organization. Section 2 introduces notation and terminology that will be used later. Section 3 illustrates the difficulty in updating dominator trees, and it defines our problem statement of updating DJ-graphs. Sections 4 and 5 together present our DJ-graph update algorithm in handling edge insertions and deletions, respectively. Section 6 discusses related work. Section 7 gives our concluding remarks. Appendix A gives the exhaustive Purdom-Moore dominator finding algorithm. Lastly,

2 Appendix B gives the Sreedhar-Gao linear time algorithm for computing iterated dominance frontiers for a set of nodes. START START 2 Background and Notation A flowgraph is a directed graph START, where is the set of nodes, is the set of flow edges, and START is the distinguished start node. Figure (a shows an example flowgraph. A path of length is a sequence of edges, where every. Given the flowgraph of a program, we define the reachable subgraph START to be a subgraph of such that all nodes in START are reachable from START. In the reachable subgraph REACH START, a node dominates another node iff all paths from START to pass through. We write to indicate that dominates, and write! when does not dominate. If and, then strictly dominates. We write! to indicate strictly dominates, and write!! when does not strictly dominate. The dominance relation is reflexive and transitive, and can be represented by a tree, called the dominator tree. For example, Figure (b shows the dominator tree of our example flowgraph. If is a parent node of in a dominator tree, then immediately dominates ; we write "$#&%(' to denote the immediate dominator of. Given a node in the dominator tree, we define +-,. to be the dominator subtree rooted at. Note that the nodes in +,/. is simply the set of all nodes dominated by. For each node in the dominator tree we associate a level number that is the depth of the node from the root. We write 2 to indicate the level number of a node. START3 4 is assumed to be one. The dominance frontier 576 of a node is the set of all such that dominates a predecessor of but does not strictly dominate [CFR 9]. We can extend the definition of dominance frontier 586 to a set of nodes : 576 9;: <(=?> We define iterated dominance nodes as the limit of the A A 586 B 8CD@?576 for a set of If is a set, we will use the notation E E to represent the number of elements in the set. Recently we proposed a linear time algorithm for computing the iterated dominance frontier for a set of nodes, using DJgraphs [SG95]. A DJ-graph is a dominator tree augmented with Note that a flowgraph does not need to be connected; that is, some nodes may not be reachable from the START node. ( (2 2 END Flowgraph (a Dominator Tree Figure : A flowgraph and its dominator tree join edges. A flowgraph edge is a join edge if its source node does not strictly dominate its destination node. In constructing the DJ-graph for the reachable subgraph REACH START, we first build its dominator tree and then appropriately insert the J-edges. Figure 2 shows the DJ-graph of our example flowgraph given in Figure (a. To see how a join edge is inserted, let us consider node 3. It has two incoming edges 3 and 7 3. Of these two edges only 7 3 is a join edge (since node strictly dominates 3, 3 is not a join edge. Clarification: We would like to clarify some terminology in order to avoid confusion in later discussions. Dominator trees and DJ-graphs are constructed only for the reachable subgraph REACHF STARTG. Whenever we use the phrase a flowgraph and its DJ-graph, we are referring to the reachable subgraph REACHF STARTG and its DJ-graph. A DJ-graph consists of a dominator tree and join edges. Therefore, whenever we use the term dominator tree, we also mean a DJ-graph without J-edges. Since a flowgraph and its DJ-graph contain the same set of nodes, whenever we use the term node H, the node H may belong to either the flowgraph or the DJ-graph, unless explicitly specified by using subscript notation with I for flowgraph and J for DJ-graph. When we describe a graph property without using subscripts, the property holds on both a flowgraph and its DJ-graph. Finally, the iterated dominance frontier of a node K is the same when computed on either the DJ-graph or the flowgraph. Thus, all of LMONPFQKRG, LMONPFSK2T&G and LMONPFSK22G will mean the same thing. (b 7 END 2

3 START END Figure 2: The DJ-graph of the example flowgraph sing the DJ-graph, we can easily compute the dominance frontier of a node based on Lemma 2.. When computing 576, we examine all the J-edges coming out of +-,.. The destination nodes of these J-edges are in the dominance frontier of when they satisfy certain level constraint [SG95]. We have also extended the above intuition and proposed a linear time algorithm for computing the iterated dominance frontier for a set of nodes [SG95]. Lemma 2. A node is in 586 in +,. 2. if and only if there exists a node 2 such that is a J-edge and 3 3 Dominator pdate: Motivation and Problem Definition Carroll and Ryder pointed out in [CR88]: The inherent difficulty in the dominator update problem lies in the non-locality of domination, to wit, given two nodes and in the flow graph, whether dominates depends on the presence or absence of paths through nodes arbitrarily far from either or. Adding or removing a single flow graph edge an act which can add or remove large numbers of paths can thus affect domination between nodes arbitrarily far from the altered edge. Consider our example flowgraph and its dominator tree shown in Figure (a and (b, respectively. Let us see what happens when a new edge 2 4 is inserted. With this new edge, the dominance relation for many nodes is affected. For example, in the newly modified flowgraph, node 3 will no longer dominate 4. Actually node 3 ceases to dominate 6 and 8 as well. The reason for this is obvious: By inserting 2 4 we have created alternative paths from START to nodes 4, 6 and 8 that do not pass through node 3. Notice that the insertion of 2 4 has affected node 8 that is far from both nodes 2 and 4. The situation is also true (but opposite when an edge is deleted; this deletion can again affect nodes arbitrarily far away. Also notice that, in the above example, the flowgraph becomes irreducible after 2 4 is inserted. Previous approaches to this problem that we are aware of, the Carroll-Ryder and the Ramalingam-Reps algorithms, cannot proceed further when this happens. Both methods use properties of flowgraphs and the dominance relation that are only valid for reducible flowgraphs. In our approach, we use properties of DJ-graphs to update dominator trees. These properties are valid for both reducible and irreducible flowgraphs. Consequently, we can handle irreducible flowgraphs while the previous approaches could not. One of our important observations is that the dominator tree alone is not sufficient to capture all the path information in a flowgraph; it only gives one type of path relationship among nodes in a flowgraph meaning, a node dominates another node iff all paths from START to must pass through. By adding J-edges to the dominator tree (a la DJ-graph we capture all the path in a flowgraph. Thus in a DJ-graph we capture both the path information and the domination relation in a unified representation. This allows us to easily compute the set of affected nodes when an edge is added or deleted. A node is called affected iff its immediate dominator will change because of a flowgraph update. Therefore, a key question to be answered in the rest of this paper is: how can we efficiently compute the set of affected nodes no matter how far away they may be from the updated edge? To summarize, the problem we consider in the next two sections is the DJ-graph update problem: We want to maintain the DJ-graph for the reachable subgraph of a flowgraph in which changes are made one at a time. This problem subsumes the dominator tree update problem. The algorithms given in Figures 3 and 5 collectively form our incremental algorithm for maintaining the DJ-graph when a new edge is inserted and an existing edge is deleted, respectively. These algorithms handle situations where and are reachable from START both before and after an update. We will handle other situations as special cases. 4 Dominator pdate: Insertion of an Edge In this section, we present a simple algorithm for updating the DJ-graph (and hence the dominator tree of a flowgraph in response to a flowgraph edge insertion. Recall that when an edge T T is inserted, it can affect nodes arbitrarily far away. One of our key observations is that all the affected 3

4 5 C pdateinsertedge : 2: 3: if! 4: " E C8@?576 "! #$# 5: foreach ( do 6: " #&%R' 7: + / cut the old D-edge / 8: if( T T is a flowgraph edge 9: "$! #$# : endif : "$ #$# / new D-edge / 2: endfor 3: foreach -. do 4: pdatelevelnumber 5: endfor 2 2 / if % '& H then we should insert a D-edge. See step / ; /? is the (old immediate dominator / / insert a J-edge from? to,9 / / pdate the level for nodes in / F7, G / Figure 3: An incremental algorithm for updating a DJ-graph when a new edge corresponding flowgraph is inserted into the nodes must be in the set is as follows: By inserting the edge T. The reason for this T, we may have created a path (in the flowgraph from STARTT to a node, say T, in T C@?586 T such that the path includes T T but bypasses the immediate dominator of T. However, not all the nodes in C7@?586 will be truly affected. We will formally prove later that the affected nodes are only those additionally satisfying certain level constraint. Once we find the exact set of affected nodes, we need to answer: What will be their new immediate dominators after the edge insertion? First note that will definitely dominate all the affected nodes. Ramalingam and Reps gave a stronger claim to answer this question: Not only does dominate all the affected nodes, but also it is actually their immediate dominator (Lemma 4.. We will utilize this claim in our algorithm too. Before presenting our algorithm for handling an edge insertion, we want to clarify the following point: We do not incrementally maintain the iterated dominance frontiers (IDFs for all the nodes in our approach. There are two reasons. First, we have a very efficient algorithm for in linear time when we are told that T T is the newly inserted edge [SG95]. Second, if we were to update IDFs, we would need to pay extra space and time overhead. The time required for updating IDFs for all the nodes can be much longer than that spent in for one node. 4. Algorithm Let T T be the newly inserted flowgraph edge. Assume that both T and T are reachable from START even before the insertion. The algorithm in Figure 3 gives a procedure to restructure the DJ-graph in response to changes in the dominance relation when T T is inserted. There are two supporting functions used in the algorithm: ( "$! #$# %(.85 #$# inserts into the DJ-graph a new edge of the appropriate type; and (2 + deletes. In the algorithm, we first compute 8 (step. Then we compute, at step 2, the set of affected nodes. E 2 : 3 2 ;. There are two conditions for a node to be in. : ( it must be in and (2 its level number must be greater than 2. sing our linear time algorithm for on-the-fly, we thus can avoid processing any node whose level number is not greater than 2 [SG95]. 2 Once we have computed., we pull up each affected node and make (i.e., its new immediate dominator (step. We also delete the D-edge to every affected node from its (old immediate dominator (step 7. If there is a flowgraph edge between these two nodes, we insert a J-edge in place of the deleted D-edge at step 8. Finally, we update the level number for all the descendant nodes of every affected nodes at step 4. Example. Consider our example flowgraph in Figure (a and its DJ-graph in Figure 2. Let us insert a new edge 2 4 in the flowgraph. The resulting flowgraph is shown in Figure 4(a. From the DJ-graph (in Figure O 2 we 9 can find 2 4 and compute After this we pull up all the affected nodes and make node their new immediate dominator. At the same time, we remove D-edges 3 4, 3 6 and 3 8. Since node 2 does not dominate 4, we insert a new J-edge 2 4. We also insert J-edges 3 4 and 3 8 in the DJ- 2 For convenience we provide a high-level description of our linear time algorithm in Appendix B. 4

5 graph, because their counterparts exist in the flowgraph. The updated DJ-graph is given in Figure 4(b. 4.2 Correctness and Complexity In this subsection, we prove the correctness of the algorithm given in Figure 3 (Theorem 4. and analyze its complexity (Theorem 4.2. Without loss of generality, we assume that T and T are reachable both before and after the insertion of T T. Theorem 4. is the main theorem that establishes the correctness of the algorithm. Its proof is based on Lemmas 4. and 4.4. Lemma 4. claims that a unique node will be the new immediate dominator of all the affected nodes. Lemma 4.4 gives a necessary and sufficient condition to determine the exact set of affected nodes. Its validity is further based on two other lemmas, Lemma 4.2 and Lemma 4.3. Lemma 4.2 claims that strictly dominates. Lemma 4.3 then "$#&%(' establishes a relation between any two nodes and when D@?586 and is reachable from. Lemma 4. Let T T be a newly inserted edge and let. Then must immediately dominate every affected node after the insertion. Proof: Let be affected after T T is inserted. Note that dominates even in the new flowgraph (since there exists no path from START to that avoids. Let be the new immediate dominator of after the insertion. Note that cannot be "$#&%(' before insertion (since is affected. Suppose that were not. Then!!. Consider any path : T T T T in the new flowgraph. must include T since. There are two possibilities: "$#&%('. Node T is in T T. This implies that T is also on any path from T to T before T T is inserted. Therefore, should have been the nearest common ancestor of and 8.. This contradicts 2. Node T is in T T. This implies that the insertion of T T should not have affected. Therefore, is already s immediate dominator before the edge insertion, so should not be affected. This contradicts our assumption that is an affected node. 2 START END Flowgraph (a START END DJ-graph Figure 4: The flowgraph and its DJ-graph after 2 (b 4 inserted Lemma 4. claims that, before the DJ-graph is updated, will be the new immediate dominator of all the affected nodes (after the update. This was originally given by Ramalingam and Reps in [RR94]. The lemma is one key result to support the correctness of our algorithm. It also forms the basis for our second key result (Lemma 4.4. Since neither possibility can be true, must be the same as ; that is, must be the immediate dominator of any affected node. To prove our second key result (Lemma 4.4, we need the following two supporting lemmas. Lemma 4.2 establishes a relation between a node and the immediate dominator of a. node Lemma 4.2 If Proof: Let then! the lemma. "$#&%R', then "$#&%(' sdom.. We will first show that if 586. sing this result we will prove the validity of Assume that does not strictly dominate. Then there must be a path from START to that does not pass through. Since 586, there must be a predecessor node strictly dominated by (follows from Lemma 2.. From this we can immediately see that there is a path from START in the DJ-graph that does not pass through, contradicting the assumption that "$#&%R'. Therefore!. Now, then there exist nodes + + such that +, +, and , where ". So we have "$#&%(' +! +, ". Consequently, "$#&%(' + "$#&%(' +, ". Hence "$#&%(' + "$#&%(' + ; that is, "$#&%(' "$#&%R'. This implies "$#&%('!. The next supporting lemma establishes a relation between any two nodes and such that is reachable from but is not This result is similar to Lemma 4 in [CFR 9]. 5

6 E C Lemma 4.3 Let be reachable from another Then there exists a node sdom. C7@?586, and let such that Proof: Assume!! (otherwise, the proof is trivial. Since is reachable from, let be a path from to. Let be the node on such that and is closest to among all nodes which are on and are must exists (e.g. in the extreme can be such a.. Such a Now we claim that all nodes on between and must be dominated by. We show this claim by contradiction. Assume that some of these nodes are not dominated by. Let + be one such nodes that is closest to on. Then by definition of dominance frontiers, + must be in 586 (hence a contradiction (since we know is the only node which lies between and! Based on this claim, we state that must be strictly dominated by. Otherwise, will be in 586 (hence ; this contradicts our lemma assumption. Next we present Lemma 4.4. sing this lemma we can determine the exact set of nodes that are indeed affected when a flowgraph edge T T is inserted. Before the edge was inserted, there must have been a path from "$#&%(' to that avoided ; for otherwise would also dominate, and so would not be the immediate dominator of. As a consequence, before the edge was inserted, must have already dominated. For if not, there would have been a path from START to avoiding, and this path could be continued as in the previous paragraph to u still avoiding. Since the path would still exist after insertion of the edge, this would contradict the fact that is the immediate dominator of after insertion. Hence before insertion, we must have ; i.e ". Next we will show that is either or is It is obvious to see that that if is same as, is in.. Now assume that. We will show that DD@?586. Assume to the contrary that is not Since is reachable from, either strictly dominate or there must be a node that strictly dominates (follows from Lemma 4.3. In both cases we can see that is not affected. But we know that is indeed affected, so must be Lemma 4.4 Let T T be a newly inserted edge in the flowgraph, and let. Let DomAffected and 2 2. Then a node is affected iff D DomAffected I. Proof: The if part: We want to show that if is in. then it is affected. Let "$#&%(' before T T is inserted. Since is in., This implies Thus we first conclude that cannot be the same as. also implies, or The fact If, then!. then " #&%R'! by Lemma 4.2. In summary, must strictly dominate. But!! because otherwise, in place of, would have been the nearest common ancestor of and (since Now consider the insertion of T T in the flowgraph. Since does not strictly dominate, the edge insertion creates at least one path STARTT T T A T that bypasses T both when and Consequently, is truly affected. The only if part: Here we will show that if is affected then is in.. First we will show that if is affected then 2 2. Finally, we state our first main theorem that establishes the correctness of our algorithm for handling an edge insertion. Theorem 4. The algorithm in Figure 3 correctly updates the DJgraph of a flowgraph when a new edge T flowgraph. T is inserted in the Proof: From Lemma 4. we know must immediately dominate all the affected nodes. Now to determine which nodes are indeed affected we use Lemma 4.4. Since we can in linear time with respect to the number of outgoing D-edges and J-edges from the nodes in +-,. (see [SG95] for details, the set. can also be computed in linear time. In addition, the time complexity for computing 8 is linear with respect to the number of nodes in +,/., and the functions "$ and + take time. Therefore, the worst-case time complexity for updating the DJ-graph in response to a flowgraph edge insertion is. Note that we never visit nodes outside of in the update process. +-,. Our second main theorem gives the worst-case time complexity of the algorithm given in Figure 3. Theorem 4.2 Assume that both T and T are reachable before the insertion of T T. Then the worst-case time complexity of the algorithm given in Figure 3 is, where is the number of edges. in the DJ-subgraph induced by the nodes in +-,. 6

7 4.3 Other Cases Let T T be the newly inserted edge in the flowgraph. Here we will describe how to handle other cases where the reachability of T and T from STARTT is different from what we have assumed in the previous subsection. The first case is where T is not reachable, for which we do nothing because we maintain the DJ-graph only for the reachable subgraph REACH START. In the second case, T becomes reachable only after the edge insertion. For this we first build (using exhaustive algorithm the DJ-subgraph for the sub-flowgraph induced by nodes reachable from T but not reachable from STARTT. In constructing this DJ-subgraph, we treat as its root. Since must dominate, we then insert a D-edge from to (to connect the newly built DJ-subgraph with the existing DJ-graph. Finally, from the viewpoint of updating DJ-graph, we pretend each T to be a newly inserted flowgraph edge, where edge T T becomes reachable only after T T is inserted, and T is reachable even before the edge insertion. This surprisingly corresponds to the case discussed in the previous subsection. To complete the DJ-graph update, we invoke the algorithm given T. in Figure 3 once for each T For example, node 9 is unreachable in Figure (a, but becomes reachable after we insert 9. Therefore, we first construct the DJ-subgraph for the sub-flowgraph induced by nodes 9,, and. Then we insert a D-edge from to 9. Finally, we use the algorithm given in Figure 3 to update the DJ-graph once for 5 and once for 7 as if they were newly inserted flowgraph edges. 5 Dominator pdate: Deletion of an Edge In this section, we show how to update a DJ-graph when a flowgraph edge T T is deleted. The effect of deleting an edge is opposite and complementary to that of inserting the same edge. When inserting T T, we pull up the affected nodes in the DJ-graph to the level of 2. Note that if. is not empty, it must include. Therefore, all the other affected nodes will be siblings to after the DJ-graph update. By contrast, when deleting T T, we pull down these affected nodes. In the deletion case, however, we have two major difficulties. First, it is hard to find the exact set of affected nodes. Second, the new immediate dominators of the affected nodes can be different. To overcome the first difficulty, we use a conservative approximation for the set of affected nodes. This set of possibly affected nodes is. E Since this set is a safe approximation, not every node in the set will be pulled down 3. can possibly be reduced by removing any node such that is a flowgraph edge, since can never be pulled down. For simplicity, we use only the two given conditions to determine if a node is in. in response to a flowgraph edge deletion. To overcome the second difficulty while avoiding an exhaustive algorithm, we observe that the new immediate dominator of any affected node must be a descendant of "$#&%('. Therefore, if any update on the DJ-graph needs to happen, it will only affect the nodes in +-,. "$#&%R'. Based on these two observations, we present an efficient incremental algorithm for only computing the possibly affected nodes new dominators, which are then used to compute their new immediate dominators. 5. Algorithm As pointed out previously, our approach to updating a DJ-graph in response to a flowgraph edge deletion will be centered at an incremental algorithm for computing the new dominators for all the possibly affected nodes. In the following, we will explain how we transform the exhaustive Purdom-Moore algorithm into an incremental algorithm that will be much more efficient in practice. The original Purdom-Moore algorithm is given in Appendix A for reference. Let 58%(' denote the set of dominators for node. Our modifications to the exhaustive Purdom-Moore algorithm are the following: First, " #&%R' will continue to dominate every possibly affected node in after the update, although it may no longer be its immediate dominator. We, therefore, can focus on the nodes in +-,. while ignoring others. Consequently, we will compute the 58%(' sets for all the possibly affected nodes as if no other nodes existed outside of +-,.. Second, we will monitor the ;&;# condition (step 39 in Algorithm A. only for the possibly affected nodes. Third, whenever 58%(' changes for a node (., the 57%R' set also changes for every descendant of. This seems to indicate that we also must observe the ;&;# condition for any descendant of every possibly affected node. Fortunately, 58%R' can be partially deduced from 58%R' as explained later. For our algorithm design, we partition all the nodes in into three classes: +-,.. PossiblyAffected: The set of nodes in this class is the same as. 2. PseudoAffected: This set consists of any proper descendant of a PossiblyAffected node. Note that a! & node s immediate dominator does not change, but its dominators may change. 3. NotAffected: This set is defined to capture all the nodes not in the first two classes. Neither does a!d "& node s immediate dominator change, nor do its dominators. 4 from the flow- For example, consider deleting 2 graph in Figure By examining 7

8 the DJ-graph in Figure 4(b, we will find that ( nodes 3, 4, 6 and 8 are!! & nodes; (2 nodes 5 and 7 are! & nodes; and (3 nodes and 2 are!d & nodes. Next we partition 58%R' for each node +-,. "$#&%R' into two parts: the static part 57%R' and the dynamic part 58%('. The static part captures nodes that will continue to dominate after the update. For example, consider the DJ-graph shown in Figure 4(b. Node and 2 will dominate node 2 even after the edge deletion, so 58%(' 2 2. By contrast, the dynamic part of a 57%R' set normally will change during the fixed point iteration. We are interested in 58%(' for only the!! & nodes because we want to compute their immediate dominators. Therefore, we carefully initialize and manipulate the 58%(' set in such a way that we update the 58%R' set only for the PossiblyAffected nodes. Let "$#&%R'. The first step of our approach is to initialize the 58%R' set for each node according to its class as follows. PossiblyAffected. For each PossiblyAffected node, 58%(' and 58%R' = all the nodes in +-,.. We basically need to recompute the dominators for each PossiblyAffected node. For instance, consider the DJ-graph in Figure 4(b. Node 4 is in PossiblyAffected and 57%R' PseudoAffected. Recall that the immediate dominator of a! & node will not change, but its 58%(' set may. Let be a PseudoAffected node. By definition, there will be a unique node!! "& that strictly dominates. Here we will discuss how to initialize the static part and compute the dynamic part of 58%('. Let be the set of nodes on the dominator tree path from to (excluding. All the nodes in will still dominate even after the update, so they are used to initialize 58%('. For example, consider the DJgraph in Figure 4(b again. The set for 5 is 5, so 58%(' D 5 5. Now for the dynamic part, we can see that the nodes in 58%(' that is not accounted for by the static part are all the nodes dominating. This implies that 58%(' is the same as 58%R'. Returning to our example; 58%(' %R' 3 57%R' 3 NotAffected. For a!d & node, neither its 58%(' set nor its immediate dominator will change. Therefore, we initialize 58%R' to be all the nodes dominating, and make its dynamic part empty. Again consider the DJ-graph in Figure 4(b. Node 2 is a NotAffected node, and 58%(' 2 2. Given the above initialization we present the algorithm shown in Figure 5. When the algorithm terminates, the dominators for each PossiblyAffected node will be in 58%R'. sing this information, we can easily determine the immediate dominators for all the possibly affected nodes. After this we can update the DJ-graph accordingly. In the above algorithm, after the completion of step 25 foreach loop, the variable 57%R'7, ' contains the intersection of the 58%(' sets from a node s immediate predecessors. There are two key points to note in this algorithm: ( We check the ;&;# condition only for the nodes in PossiblyAffected; and (2 If an immediate predecessor at step 26 belongs to! &, we make 58%(' be 58%(', where!! & and!. We, therefore, do. not explicitly recompute the dynamic part of 58%R' Example. Consider the flowgraph and its DJ-graph shown in Figure 4. Assume that 2 4 is to be deleted from the flowgraph. To update the DJ-graph, we first incrementally compute the 58%(' set O for every possibly af- fected node. Since , we have!! & ,!" & 5 7, and!d & 2. Also "$#&%(' O 4. The table in Figure 6 (a gives the initial values of the 58%R' sets. J6 J639K6 M -F$G M &F$G 3 PossiblyAffected N 4 PossiblyAffected N 6 PossiblyAffected N 8 PossiblyAffected N 5 PseudoAffected 5 M F 3G 7 PseudoAffected 7 M F 6G NotAffected 2 NotAffected 2 (a J6 56BJ2T M 3 6 & M F G & =! #"%$ M F& G M 3 6 (' J , (b for the exam- Figure 6: (a Initial and (b Final values of 58%R' ple. (In the above tables The fixed point value for the possibly affected nodes is shown in Figure 6 (b. As can be seen, our example converges in one iteration! Observe that when computing 57%R'7, ' at step 29 we always select the latest value of 58%('. In addition, whenever such a is a PseudoAffected node, we update its 58%(' set at step 26. In the actual implementation, we do not need to update 58%R' for! &. sing pointer data structures we can easily point to the set 58%(', where is an ancestor of and!! "&. 8

9 # T pdatedomdel 6: E $ : if! "$#&%(' / do not cut if H K is a D-edge! / 8: + 9: "$#&%(' 2: Partition all the nodes in +,/. 2: Initialize each node +-,. as described in the main text. 22: while( &# to any 58%(' such that!! & occur do 23: foreach!! "& do 24: 58%('7, ' +-,. / temporary variable / 25: foreach T. do / T is an immediate predecessor in the flowgraph / 26: if! "& 27: 58%(' 9 57%R', where!! & and! 28: endif 29: 58%('8, ' 58%('8, ' 58%(' C 58%(' 3: endfor 3: 58%(' C 57%R'7, ' into PossiblyAffected, PseudoAffected, and NotAffected. 32: endfor 33: endwhile 34: Compute the immediate dominators for all the possibly affected nodes. 35: pdate the DJ-graph accordingly. Figure 5: An incremental algorithm for updating a DJ-graph when an existing edge corresponding flowgraph is deleted from the Once we have computed the 58%(' sets, we can easily determine the new immediate dominators for all the affected nodes. In our example, node is the new immediate dominator of 3, which is the new immediate dominator of 4, 6 and 8. With this information we can proceed to update the DJ-graph. The updated DJ-graph is shown in Figure 2. One key point to observe in the above algorithm is how we initialize the starting solutions for different types of nodes (i.e., the 58%(' sets. If we were to start the iteration from the old fixed point (i.e., 57%R' initialized to the old the dominators we would get wrong result. We leave this as an exercise for readers to verify. For a comprehensive treatment on this and other related problems of incremental iteration, please see [RMP88, Mar89]. Another approach for updating the dominator tree when an edge is deleted is to apply fast exhaustive algorithms such as Lengauer and Tarjan s algorithm [LT79] or Harel s linear time algorithm [Har85] on the subgraph induced by the +-,. "$#&%R'. It will be interesting to see how the fast (or the linear exhaustive algorithm performs compared to our incremental algorithm. We are currently working on such experiments and will report the results in the future. 5.2 Correctness and Complexity In order to find the new immediate dominators for all the possibly affected nodes, we use the algorithm given in Figure 5 to find their new dominators instead. Consequently, the correctness of our approach to handling an edge deletion relies on the correctness of finding the dominators for every!! & node. The following lemma claims that when the algorithm given in Figure 5 terminates, the dominators for every & nodes are correctly found.!! Lemma 5. Let T T be the deleted flowgraph edge. Assume "$#&%('. Then that we are only interested in nodes in +,/. when the algorithm given in Figure 5 terminates, 58%(' contains exactly all the dominators for any PossiblyAffected node. Proof: Even though we do not initialize the 58%R' set for all the nodes in the same way as the exhaustive Purdom-Moore algorithm does, we still use over-estimates (as the Purdom- Moore algorithm to initialize all the 58%R' sets as described in the text. That is, the initial value of 58%(' for any node includes all the dominators of (as well as other nodes that are not dominators of. Therefore, no dominators of will be missing from the final 57%R', regardless of being a!! &! "& or!d & node. The meet operation used in the fixed point iteration is the set intersection operation. As the Purdom-Moore algorithm will converge, our algorithm will converge too (but faster with the same solution for each!! contains exactly all the dominators of. 58%(' & node. Thus, In the worst case, the time complexity of the algorithm given in Figure 5 can be the same as the Purdom-Moore algorithm. In practice, however, we expect our algorithm to be much faster in the average case. 9

10 5.3 Other Cases Let T T be the edge to be deleted from the flowgraph. Here we will describe how to handle other cases where the reachability of T and T from STARTT is different from what we have assumed. If is not reachable, then we do nothing because we only intend to maintain the DJ-graph for the reachable subgraph REACH START. Now assume that is reachable and becomes unreachable after deletion. In this case, we remove from the DJ-graph all the and their incident edges. This is because nodes in +-,. if removing T T makes T become unreachable, then all the nodes strictly dominated by will not be reachable either. Next, we remove the D-edge. Finally, we update the reachability status for all the nodes that become unreachable due to the edge deletion. 6 Related Work In this paper we have presented an approach to the DJ-graph update problem, which subsumes that of updating dominator trees. Previous work, most relevant to our approach, for the dominator tree update problem includes the Carroll-Ryder algorithm [CR88] and the Ramalingam-Reps algorithm [RR94]. Both these algorithms are restricted to the class of reducible flowgraphs. By contrast, our algorithm can handle irreducible as well as reducible flowgraphs. The Ramalingam-Reps algorithm for updating dominator trees is different from the Carroll-Ryder algorithm. Our approach is comparable to the Ramalingam-Reps approach, while there are a number of significant differences. We will first compare ours with Ramalingam and Reps approach. 6. Ramalingam and Reps To simplify the presentation, we will refer to Ramalingam and Rep s algorithm as the RR algorithm.. nlike the RR algorithm, ours can handle both reducible and irreducible flowgraphs. 2. The RR algorithm is based on the properties of pseudocircuit value problem [AHR 9], while we use properties of DJ-graphs and IDFs to update the DJ-graphs. They use a modified algorithm of Alpern et al. to update the priorities of nodes. Priorities are equivalent to reverse topological sorting of the nodes in the forward flowgraph. 4 Priorities can be assigned to nodes only if the forward flowgraph is a directed acyclic graph. This property is only true for reducible flowgraphs. During the insertion 4 Intuitively, a forward flowgraph is nothing but a reducible flowgraph with all back edges removed. An edge in a flowgraph is a back edge if its destination node dominates its source node [AS86]. of a new edge, if a cycle is detected in the forward flowgraph, then their algorithm immediately signals that this insertion has introduced irreducibility into the flowgraph. After that they do not allow further insertions and deletions of edges, because they cannot assign priorities to nodes in the forward flowgraph containing cycles. 3. In the insertion case, our algorithm can begin with the precise set of affected nodes (e.g. & (, while the RR algorithm needs to begin with a conservative set of possibly affected nodes. When an edge T T is deleted, Ramalingam and Reps make all the sibling nodes of be affected. Our set of possibly affected nodes, although not precise, is always a subset of s sibling nodes; therefore, it is a better approximation than theirs. 4. Since the two algorithms are fundamentally different, it is difficult to make precise statements on their timing comparisons without substantial tests on real programs. In particular, it is generally very difficult to analytically compare incremental algorithms [Mar89, Ram93]. Therefore, we only make some qualitative observations. Our algorithm, for the insertion case, begins by computing precisely the set of affected nodes, at the expense of visiting arguably more nodes compared to the RR algorithm. (This is true even for the deletion case. On the other hand, the RR algorithm has a %# overhead factor (in the worst case. Also the RR algorithm has to do priorityupdating. One way to compare the performance of the two algorithms is to implement and test them on real benchmark programs. We are currently in the process of implementing our algorithm. We will report our empirical result in the near future. 6.2 Other related work The Carroll-Ryder algorithm uses two local properties: niceness and deepness. Niceness is a property for edges; deepness is a property for nodes. Non-nice edges and non-deep nodes cannot exist in the dominator tree of a reducible graph. sing these two local properties and the notion of representative edges, they maintain the dominator tree of a reducible flowgraph. However, it could be expensive to maintain such auxiliary information as representative edges. Ramalingam and Reps have presented detailed comparisons between their work and the Carroll-Ryder algorithm. Their comparisons are applicable to our work. We direct interested readers to their paper [RR94]. In a recent paper [JPP94], Johnson et al. introduced the Program Tree Structure (PST for performing fast program analysis. The PST represents a program with a hierarchy of singleentry, single-exit regions. sing the PST, Johnson in his thesis proposed an algorithm for updating dominator trees [Joh94]. His approach is to identify regions, corresponding to subflowgraphs, where the dominance relation may no longer be correct because of a flowgraph edge update. Once a region is

11 identified, he applies an exhaustive algorithm for all the nodes in this region. 7 Conclusion and Future Work We presented a new algorithm for updating DJ-graphs (and hence dominator trees for arbitrary flowgraphs, both reducible and irreducible. We are currently implementing our algorithm and intend to profile its performance on real benchmark programs. The result presented in this paper can be used for updating other data/control flow properties, such as data flow information [CR88], -nodes [SGL94b], and incremental SSA forms [CSS94]. Acknowledgements The first two authors thank the National Sciences and Engineering Research Council (NSERC and the Canadian Centers of Excellence (IRIS for their continued support of this research. We thank Tom Marlowe for his insightful comments. We thank G. Ramalingam for pointing out a small error in the insertion algorithm and also clarifying many points regarding his original algorithm. Finally, we thank the reviewers for their comments, which greatly improved the overall presentation of this paper. [CFR 9] [CLZ86] [CR88] [CSS94] efficient method for computing static single assignment form. In Conference Record of the Sixteenth Annual ACM Symposium on Principles of Programming Languages, pages 25 35, Austin, Texas, January 3, 989. ACM SIGACT and SIGPLAN. Ron Cytron, Jeanne Ferrante, Barry K. Rosen, Mark N. Wegman, and F. Kenneth Zadeck. Efficiently computing static single assignment form and control dependence graph. ACM Transactions on Programming Languages and Systems, 3(4:452 49, October 99. Ron Cytron, Andy Lowry, and Kenneth Zadeck. Code motion of control structures in high-level languages. In Conference Record of the Thirteenth Annual ACM Symposium on Principles of Programming Languages, pages 7 85, St. Petersburg Beach, Florida, January 3 5, 986. ACM SIGACT and SIGPLAN. M. Carroll and B. G. Ryder. Incremental data flow update via attribute and dominator updates. In ACM SIGPLAN-SIGACT Symposium on the Principles of Programming Languages, pages , January 988. J. D. Choi, V. Sarkar, and E. Schonberg. Incremental computation of static single assignment form. npublished manuscript, 994. References [AHR 9] B. Alpern, R. Hoover, B. Rosen, B. K. Sweeney, and F. K. Zadeck. Incremental evaluation of computational circuits. In Proceedings of the First Annual ACM-SIAM Symposium on Discrete Algorithms, pages 32 42, 99. [AS86] [AWZ88] [CCF9] [CFR 89] A. V. Aho, R. Sethi, and J. D. llman. Compilers Principles, Techniques, and Tools. Addison-Wesley Publishing Co., 986. Bowen Alpern, Mark N. Wegman, and F. Kenneth Zadeck. Detecting equality of variables in programs. In Conference Record of the 5th Annual ACM Symposium on Principles of Programming Languages, pages, 988. Jong-Deok Choi, Ron Cytron, and Jeanne Ferrante. Automatic construction of sparse data flow evaluation graphs. In Conference Record of the 8th Annual ACM Symposium on Principles of Programming Languages, 99. Ron Cytron, Jeanne Ferrante, Barry K. Rosen, Mark N. Wegman, and F. Kenneth Zadeck. An [Har85] Dov Harel. A linear time algorithm for finding dominators in flow graphs and related problems. In Symposium on Theory of Computing. ACM, May 985. [Joh94] [JPP94] [LT79] Richard Johnson. Dependence Based Program Analysis. PhD thesis, Cornell niversity, Ithaca, New York, August 994. R. Johnson, D. Pearson, and K. Pingali. The program tree structure: Computing control regions in linear time. In Proceedings of the SIGPLAN 94 Conference on Programming Language Design and Implementation, pages 7 85, 994. T. Lengauer and Robert Tarjan. A fast algorithm for finding dominators in a flowgraph. ACM Transactions on Programming Languages and Systems, (:2 4, July 979. [Mar89] Thomas J. Marlowe. Data Flow Analysis and Incremental Iteration. PhD thesis, Rutgers niversity, New Brunswick, New Jersey, October 989. [Ram93] G. Ramalingam. Bounded Incremental Computation. PhD thesis, niversity of Wisconsin-Madison, Madison, Wisconsin, August 993.

12 C [RMP88] B. G. Ryder, T. G. Marlowe, and M. C. Paull. Conditions for incremental iteration: Examples and counterexamples. Science of Computer Programming, (: 5, October 988. [RR94] G. Ramalingam and T. Reps. An incremental algorithm for maintaining the dominator tree of a reducible flowgraph. In ACM SIGPLAN-SIGACT Symposium on the Principles of Programming Languages, January 994. [RWZ88] [SG95] [SGL94a] [SGL94b] Barry K. Rosen, Mark N. Wegman, and F. Kenneth Zadeck. Global value numbersand redundant computations. In ACM SIGPLAN-SIGACT Symposium on the Principles of Programming Languages, pages 2 27, January 988. Vugranam C. Sreedhar and Guang R. Gao. A linear time algorithm for placing -nodes. In ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, January 995. A longer version accepted in Journal of Programming Languages. Vugranam C. Sreedhar, Guang R. Gao, and Yongfong Lee. DJ-graphs and their applications to flowgraph analyses. TechnicalReport ACAPS Memo 7, McGill niversity, May 994. Vugranam C. Sreedhar, Guang R. Gao, and Yongfong Lee. An efficient incremental algorithm for maintaining dominator trees and its application to -nodes update. Technical Report ACAPS Memo 77, McGill niversity, July 994. [WCES94] Daniel Weise, Roger F. Crew, Michael Ernst, and Bjarne Steensgaard. Value dependence graphs: Representation without taxation. In ACM SIGPLAN-SIGACT Symposium on the Principles of Programming Languages, January 994. [WZ85] A Mark Wegman and Ken Zadeck. Constant propagation with conditional branches. In Conference Record of the Twelfth Annual ACM Symposium on Principles of Programming Languages, pages ACM SIGACT and SIGPLAN, January 985. Purdom and Moore s Algorithm Here we give the original Purdom and Moore s exhaustive algorithm for computing the dominator set. The version of the algorithm is adapted from [AS86]. Algorithm A. (Finding Dominators. The following is an iterative algorithm for computing the dominator set. 36: 58%R' 37: foreach 9 START START START do 38: 58%(' / end initialization / 39: while ;&;# to any 58%(' occur do 4: foreach D START do 4: 57%R' =! #"%$ 57%R' B Sreedhar and Gao s Algorithm Here we briefly introduce Sreedhar and Gao s linear time algorithm [SG95] for computing the iterated dominance frontiers for a set of node. The algorithm is based on two key observations:. Let be an ancestor of on the dominator tree. If 576 has already been computed before the computation of 586, then 576 need not be recomputed when computing 586. However, the reverse may not be true; therefore, the order of the computation is crucial. We order the computation of the relevant set of nodes in a bottom-up fashion using the levels of the nodes in the dominator tree. 2. The computation of 586 itself is guided by D-edges in a top-down fashion. When computing 586 we only need to examine the J-edges, where is a node in the dominator subtree rooted at and is a node whose level is no greater than the level of. To order the relevant set of nodes, we use a data structure called the " #$# &, which is nothing but an array of pointers to nodes, with index " storing nodes at level i. A high-level description of the complete algorithm is given below (for details please see [SG95]. Let be the initial set, whose iterated dominance frontiers are of interest to us. Initially the " #"# 9& is empty. Step Deposit all nodes in into the " #$# 9&. Remember that if " is the level number of a node then it is inserted at the index " in the " #$# 9&. Step 2 Pick a node from the " #$# 9& such that 2 is the highest level of all the nodes currently in the " #$# 9&. (Remove from the " #$# &. using Lemma 2. by walking down the +,. while avoiding nodes that have been previously visited. Deposit all the nodes in 576 back into the " #$# &, if was not previously put in the " #$# 9& and is not in. All such s will be the Step 3 Compute 586 candidate nodes Step 4 Repeat Step 2 and 3 (in that order, until there are no more nodes in the " #$# &.. 2