1. Dead Code Elimination This lecture presents the algorithm Dead from EaC2e, Chapter 10. That algorithm derives, in turn, from Rob Shillner’s unpublished work in the MSCP project and from the original SSA paper by Cytron et al. Copyright 2011, Keith D. Cooper & Linda Torczon, all rights reserved. Students enrolled in Comp 512 at Rice University have explicit permission to make copies of these materials for their personal use. Faculty from other educational institutions may use these materials for nonprofit educational purposes, provided this copyright notice is preserved. Comp 512 Spring 2011

2. Using Static Single Assignment Form Dead Code Elimination Classic approach  Mark “important” operations as critical  Any output instruction is critical  Any def that reaches a critical op is critical  Any branch required to reach a critical op is critical  Any other op is dead & can be eliminated Algorithm  Mark critical operations  Propagate those marks backward from uses to definitions  Interpret the SSA form as a sparse evaluation graph COMP 512, Rice University1

3. Tricky part of the algorithm COMP 512, Rice University2 Using SSA – Dead code elimination Mark for each op i clear i’s mark if i is critical then mark i add i to WorkList while (Worklist ≠ Ø) remove i from WorkList (i has form “x  y op z” ) if def(y) is not marked then mark def(y) add def(y) to WorkList if def(z) is not marked then mark def(z) add def(z) to WorkList for each b  RDF (block(i)) mark the block-ending branch in b add it to WorkList Sweep for each op i if i is not marked then if i is a branch then rewrite with a jump to i’s nearest useful post-dominator if i is not a jump then delete i Notes: Eliminates some branches Reconnects dead branches to the remaining live code Find useful post-dominator by walking post-dom tree > Entry & exit nodes are useful

4. COMP 512, Rice University3 Using SSA – Dead code elimination Handling Branches When is a branch useful?  When a useful operation depends on its existence j control dependent on i  one path from i leads to j, one doesn’t This is the reverse dominance frontier of j ( RDF (j)) Algorithm uses RDF (n ) to mark branches as live In the CFG, j is control dependent on i if 1.  a non-null path p from i to j  j post-dominates every node on p after i 2.j does not strictly post-dominate i

5. COMP 512, Rice University 4 Dominators Definitions x dominates y if and only if every path from the entry of the control-flow graph to the node for y includes x By definition, x dominates x We associate a Dom set with each node |Dom(x )| ≥ 1 Immediate dominators For any node x, there must be a y in Dom(x ) closest to x We call this y the immediate dominator of x As a matter of notation, we write this as IDom(x ) Original idea: R.T. Prosser. “Applications of Boolean matrices to the analysis of flow diagrams,” Proceedings of the Eastern Joint Computer Conference, Spartan Books, New York, pages 133-138.

6. COMP 512, Rice University 5 Dominators have many uses in analysis & transformation Finding loops Building SSA form Making code motion decisions We’ll look at how to compute dominators later Dominators A BCG FED Dominator tree Dominator sets * m 0  a + b n 0  a + b A p 0  c + d r 0  c + d B r 2   (r 0,r 1 ) y 0  a + b z 0  c + d G q 0  a + b r 1  c + d C e 0  b + 18 s 0  a + b u 0  e + f D e 1  a + 17 t 0  c + d u 1  e + f E e 3   (e 0,e 1 ) u 2   (u 0,u 1 ) v 0  a + b w 0  c + d x 0  e + f F

7. COMP 512, Rice University6 SSA Construction Algorithm ( Low-level detail ) Computing Dominance n dominates m iff n is on every path from n 0 to m  Every node dominates itself  n’s immediate dominator is its closest dominator, ID OM (n) † D OM (n 0 ) = { n 0 } D OM (n) = { n }  (  p  preds(n) D OM (p)) Computing DOM These equations form a rapid data-flow framework Iterative algorithm will solve them in d(G) + 3 passes  Each pass does N unions & E intersections,  E is O(N 2 ),  O(N 2 ) work † ID OM (n ) ≠ n, unless n is n 0, by convention. Initially, D OM (n) = N,  n≠n 0

8. COMP 512, Rice University7 Example B1B1 B2B2 B3B3 B4B4 B5B5 B6B6 B7B7 B0B0 Flow Graph Progress of iterative solution for D OM Results of iterative solution for D OM *

9. Dominance Frontiers & Inserting ϕ -functions Where does an assignment in block n induce ϕ –functions? n DOM m ⇒ no need for a ϕ –function in m  Definition in n blocks any previous definition from reaching m If m has multiple predecessors, and n dominates one of them, but not all of them, then m needs a ϕ –function for each definition in n More formally, m is in the dominance frontier of n if and only if 1. ∃ p ∈ preds(m) such that n ∈ DOM(p), and 2. n does not strictly dominate m (n ∉ DOM(m) – { m }) This notion of dominance frontier is precisely what we need to insert ϕ –functions: a def in block n induces a ϕ –function in each block in DF(n). COMP 512, Rice University8 “strict” dominance allows a ϕ –function at the head of a single-block loop.

10. COMP 512, Rice University9 Example Dominance Frontiers Dominance Frontiers & ϕ -Function Insertion A definition at n forces a ϕ -function at m iff n  D OM (m) but n  D OM (p) for some p  preds(m) DF(n ) is fringe just beyond region n dominates B1B1 B2B2 B3B3 B4B4 B5B5 B6B6 B7B7 B0B0 *  in 1 forces ϕ -function in DF(1) = Ø (halt ) x ... x  ϕ (...) DF(4) is {6}, so  in 4 forces ϕ -function in 6 x  ϕ (...)  in 6 forces ϕ -function in DF(6) = {7} x  ϕ (...)  in 7 forces ϕ -function in DF(7) = {1} For each assignment, we insert the ϕ -functions

11. COMP 512, Rice University10 Example Dominance Frontiers Computing Dominance Frontiers Only join points are in DF(n) for some n Leads to a simple, intuitive algorithm for computing dominance frontiers For each join point x ( i.e., |preds(x)| > 1 ) For each CFG predecessor p of x Run from p to ID OM (x) in the dominator tree, & add x to DF(n) for each n from p up to but not ID OM (x) B1B1 B2B2 B3B3 B4B4 B5B5 B6B6 B7B7 B0B0 * For some applications, we need post-dominance, the post-dominator tree, and reverse dominance frontiers, RDF(n) > Just dominance on the reverse CFG > Reverse the edges & add unique exit node We will use these in dead code elimination

12. COMP 512, Rice University11 Back to Dead Code Elimination What’s left? Algorithm eliminates useless definitions & some useless branches Algorithm leaves behind empty blocks & extraneous control-flow Two more issues Simplifying control-flow Eliminating unreachable blocks Both are transformations based on the structure of the CFG