Parallelizing the Construction of Static Single Assignment Form

More documents

Recommendations

Info

Algorithms for the construction of SSA based on data flow analysis of a control flow graph (following the style of Cytron et al [7]) can be divided into two distinct phases. 1. Insertion of φ-functions at control flow merge points, in order to satisfy the SSA property that each variable use has a single reaching definition, which dominates the use. 2. Renaming of local variables, in order to satisfy the SSA property that each variable has a single definition in the program text. In this section, we discuss how to adapt the two phases of the classical SSA construction algorithm to make them amenable for parallelism. In passing, we note that there are many other data flow based SSA construction algorithms, e.g. [28, 3, 8]. These are more efficient than the classical algorithm, although they may be more complex to implement. However in general, they have a similar structure to the classical algorithm, so it should be possible to parallelize them using similar strategies to those presented in this paper. Certain SSA construction algorithms are not data flow based, such as the syntax-directed algorithm by Brandis and Mössenböck [6]. In such cases, the strategies given in this paper would not be directly applicable. We do not consider such algorithms further in this work. 2.1 Insertion of φ-functions 2.1.1 Commentary on Sequential Algorithm The classical algorithm, shown in Algorithm 1, iterates over each variable v from the original program, to determine where to insert φ-functions for v. This is the outermost for loop starting at line 2. The algorithm is based on iteratively processing a work-list W of basic blocks, for each variable v. Initially, we insert into work-list W all basic blocks containing definition statements for v in the original program, lines 3–6. One-by-one, each basic block B is removed from W . We assume that dominance frontier information has been pre-computed for each basic block in the control flow graph. If basic block X contains a definition of v, then it is necessary to insert a φ-function for v at the beginning of all blocks in the dominance frontier of B, i.e. DF(X), lines 9–11. Blocks in DF(X) have several incoming definitions of v, and thus require a φ-function for v at the head of each block to act as a data flow merge operator. Note that we only insert a φ-fn for v if none has been inserted already. Therefore it is helpful to keep a bitvector record of where we have inserted φ-functions for v, see line 10. Now, if we do insert a φ-function, this is a fresh definition of v, so the enclosing basic block must be inserted into work-list W since it may trigger the insertion of further φ-functions at its own dominance frontier, see line 13. Again, each basic block should only be inserted into W once, so it is helpful to keep another bitvector record of which basic blocks have been inserted into W , see line 12. The φ-function insertion algorithm is guaranteed to terminate. There is a fixed number of variables in the original program, so the outermost for loop is executed for a fixed number of iterations. The control flow graph has a fixed number of basic blocks N, thus the dominance frontier of any basic block is bounded by N. Again, each basic block can only be inserted into the work-list W once, so the number of insertions into W is bounded by N. Also, each iteration of inner while loop starting at line 7 removes one item from W . So W will eventually become empty, which is the termination condition of the while loop. Algorithm 1 Classical φ-function insertion algorithm 1: W ← {} 2: for all v : variable names in original program do 3: for all d : definition statements of variable v do 4: let B be the basic block containing d 5: W ← W ∪ {B} 6: end for 7: while W = {} do 8: remove a basic block X from W 9: for all Y : block ∈ DF(X) do 10: if Y does not contain a φ-function for v then 11: add v ← φ(...) at start of Y 12: if Y has not already been processed in W then 13: W ← W ∪ {Y } 14: end if 15: end if 16: end for 17: end while 18: end for 2.1.2 Parallelization Strategy The presentation of φ-function insertion in Algorithm 1 follows the original description from Cytron et al [7]. As it stands, this is a sequential algorithm. However, it is clear to see that each variable v is processed individually in a single iteration of the outermost for loop. Variables do not interfere with one another, in terms of data flow analysis for inserting φ-functions. Therefore it is straightforward to transform the for at line 2 loop into a parallel doall loop, where all iterations may be executed in parallel. The work-list W and all local variables declared within the loop body must be privatized for each parallel loop iteration. Apart from this, the only issue is that parallel loop iterations may attempt to insert φ-functions for different variables concurrently into the same basic block. One solution is to introduce a semaphore associated with each basic block B to serialize the φ-function insertions at the head of B. However there is the likelihood of high contention on these semaphores (due to φ-functions often being located together). A more scalable solution is to maintain a private queue of (φ-function, basic block) pairs for each thread, denoting which basic blocks require particular φ-functions. Thus line 11 of the algorithm changes to: 11: add new Pair (v ← φ(. . .), Y ) to local queue All these queued φ-functions can be inserted at the end of the doall loop. Given an appropriate lookup table for the local queues that can be indexed by basic block ids, the lazy φ-insertion phase can be parallelized over basic blocks, thus avoiding the earlier problem of concurrent updates to individual basic blocks. Algorithm 2 shows this additional code. 2.2 Renaming Local Variables
Algorithm 2 Amendment for lazy φ-function insertion 19: doall B : basic blocks in control flow graph 20: for all v : variable names in original program do 21: if there is a queued φ-function for v at block B then 22: insert φ-function at block B 23: end if 24: end for 25: end doall 2.2.1 Commentary on Sequential Algorithm Once the φ-function insertion is complete, the second phase is to rename all definitions and uses of local variables to enforce the SSA property of having a single definition per variable in the program text, while respecting the original program’s data flow behaviour. The presentation of the classical renaming algorithm by Cytron et al [7] is phrased in terms of original variable names and new variable names. At each control flow point in the program, we must maintain a mapping between original variable names and new variable names. This mapping changes as variable definitions enter and exit scope. The mapping is generated using an array of stacks S, indexed by original variable name. An individual stack data structure S(V ) contains new names corresponding to original variable name V . A new variable name Vi is pushed onto stack S(V ) at the ith definition of V encountered in the original program text. At the same time, the new name Vi replaces the old name V for that particular variable definition statement. Vi is popped off the stack when its corresponding definition goes out of scope. At each statement that uses V in the original program, the new variable name Vi on top of S(V ) is substituted into the statement in place of the original name V . The CFG is processed according to a pre-order traversal of its dominator tree. The set of basic blocks Children(X) denotes the basic blocks whose immediate dominator is X, i.e. their parent in the dominator tree is X. The most complex part of the renaming algorithm involves φ-function right-hand side operands. The jth operand on the right-hand side of a φ-function for original variable V must be renamed according to the new variable name Vi that is in scope at the end of the jth predecessor basic block. Operationally, a φ-function for V at the beginning of block B is equivalent to n simple assignments to V at the end of the n predecessor basic blocks of B. Thus it is most straightforward to rename φ-function right-hand operands during the renaming of corresponding predecessor basic blocks. At each basic block, we must look ahead to check for φ-functions in successor basic blocks. The set of control flow successors for basic block B is denoted as Succ(B). Algorithm 3 gives the pseudo-code for the classical SSA renaming algorithm due to Cytron et al. 2.2.2 Parallelization Strategy The sequential renaming algorithm presented in Algorithm 3 cannot easily be parallelized using the same strategy as for the φ-insertion algorithm, i.e. one thread per variable. Such per-variable parallelism is not appropriate for the renaming phase, since each thread would have to process each statement, and would only perform a trivial amount of work at that statement. Furthermore, many variables may not be in scope for large parts of the program. Algorithm 3 Classical SSA renaming algorithm 1: for all V : variables in original program do 2: Count(V ) ← 0 3: S(V ) ← EmptyStack 4: end for 5: call Search(EntryNode) 6: 7: procedure Search(X : BasicBlock) 8: for all A : statement in X do 9: if A is not a φ-function then 10: for all u : variables used in A do 11: replace use of u with S(u) in A 12: end for 13: end if 14: for all v : variables defined in A do 15: i ← Count(v) 16: replace definition of v with vi in A 17: push vi onto S(v) 18: Count(v) ← i + 1 19: end for 20: end for 21: for all Y ∈ Succ(X) do 22: let j be the index of the φ-function operands in Y that correspond to basic block X 23: for all F : φ-function in Y do 24: let V be the jth operand in F 25: replace V with S(V ) at the jth operand in F 26: end for 27: end for 28: for all Z ∈ Children(X) do 29: call Search(Z) 30: end for 31: for all A : statements in X do 32: for all Vi : variables defined in A do 33: let V be the original variable corresponding to Vi 34: pop S(V ) 35: end for 36: end for 37: end procedure
Page 1: ABSTRACT Parallelizing the Construc
Page 5 and 6: (e.g. the control flow graph and ba
Page 7 and 8: speedup 1.6 1.4 1.2 1 0.8 0.6 0.4 0
Page 9: transformation. In: Code Generation

Parallelizing the Construction of Static Single Assignment Form

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?