Comp 512
Spring
2011
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.
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 University
1
Using SSA – Dead code elimination
Tricky part of the algorithm
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
COMP 512, Rice University
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
2
Using SSA – Dead code elimination
Handling Branches
• When is a branch useful?

When a useful operation depends on its existence
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
• 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
COMP 512, Rice University
3
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.
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 )
4
COMP 512, Rice
University
Dominators
Dominators have many uses in analysis & transformation
• Finding loops
• Building SSA form
• Making code motion decisions
A
B
m0  a + b
n0  a + b
C
p0  c + d
r0  c + d
Dominator sets
D
Dominator tree
A
B
C
G
D
E
F
e0  b + 18
s0  a + b
u0  e + f
F
G
q0  a + b
r1  c + d
E
e1  a + 17
t0  c + d
u1  e + f
e3  (e0,e1)
u2  (u0,u1)
v0  a + b
w0  c + d
x0  e + f
r2  (r0,r1)
y0  a + b
z0  c + d
We’ll look at how to compute dominators later
5
COMP 512, Rice
University
*
SSA Construction Algorithm
(Low-level detail)
Computing Dominance
• n dominates m iff n is on every path from n0 to m

Every node dominates itself

n’s immediate dominator is its closest dominator, IDOM(n)†
DOM(n0 ) = { n0 }
Initially, DOM(n) = N,
 n≠n0
DOM(n) = { n }  (ppreds(n) DOM(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
COMP 512, Rice University
†IDOM(n ) ≠ n, unless n is n , by convention.
0
6
Example
Progress of iterative solution for DOM
B0
B1
B2
B3
B4
B5
Results of iterative solution for DOM
B6
B7
Flow Graph
COMP 512, Rice University
* 7
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 University
“strict” dominance allows a ϕ–function at the
head of a single-block loop.
8
Example
Dominance Frontiers & ϕ-Function Insertion
B0
• A definition at n forces a ϕ-function at m iff
x
B1ϕ(...)
n  DOM(m) but n  DOM(p) for some p  preds(m)
• DF(n ) is fringe just beyond region n dominates
B2
B3
x
B4...
B5
x
B6ϕ(...)
x
B7ϕ(...)
Dominance
Frontiers
• DF(4) is {6}, so  in 4 forces ϕ-function in 6
•  in 6 forces ϕ-function in DF(6) = {7}
•  in 7 forces ϕ-function in DF(7) = {1}
•  in 1 forces ϕ-function in DF(1) = Ø
(halt )
For each assignment, we insert the ϕ-functions
COMP 512, Rice University
* 9
Example
Computing Dominance Frontiers
B0
• Only join points are in DF(n) for some n
• Leads to a simple, intuitive algorithm for computing
B1
B2
B3
B4
B5
dominance frontiers
For each join point x
(i.e., |preds(x)| > 1)
For each CFG predecessor p of x
Run from p to IDOM(x) in the dominator tree, & add
x to DF(n) for each n from p up to but not IDOM(x)
B6
B7
Dominance
Frontiers
• 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
COMP 512, Rice University
* 10
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
COMP 512, Rice University
11