1. More Data-flow Analysis COMP 512 Rice University Houston, Texas Fall 2003
Copyright 2003, 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.

2. The Lab Three part exercise
1. Build live variables analysis into ILOC infrastructure
2. Build pruned SSA form in the ILOC infrastructure
3. Pick a pair of optimizations (with guidance) & implement them in the ILOC infrastructure
More details next class
You may work in pairs
The lectures will cover the material needed for the lab
The goal is for you to implement a couple of real optimizations
COMP 512, Fall 2003

3. Review Last class Introduced round-robin iterative algorithm
Converges if function space is monotone and semilattice is bounded (that is, descending chains are finite)
Showed conditions under which LFP = MFP = MOP (admissibile )
Showed condition for RPO algorithm to run quickly (rapid )
Not all problems meet these conditions
Constant propagation, interprocedural may modify
COMP 512, Fall 2003

4. Round-robin Versus Worklist Algorithm
Termination, correctness, & complexity arguments are for
the round-robin version
The worklist algorithm does less work; it visits fewer nodes
Consider a version with two worklists: current & next
Draw nodes from current in RPO; add them to next
Swap the worklists when current becomes empty (1 r-r pass)
Makes same changes, in same order, as round robin
Termination & correctness arguments should carry over
Is this the best order? Maybe not …
Iterate around a loop until it stabilizes
Many data structures for worklist, many orders
Your mileage will vary (measurable effect )
Worklist algorithm is a sparse version of round-robin algorithm
COMP 512, Fall 2003

5. The Round-robin Iterative Algorithm
AVAIL(b0 )  Ø
for i  1 to N
AVAIL(bi )  { all expressions }
change  true
while (change)
change  false
for i  0 to N
TEMP  xpred (b) (DEF (x)  (AVAIL(x)  NKILL(x) ))
if AVAIL(bi ) ≠ TEMP then
AVAIL(bi )  TEMP
COMP 512, Fall 2003

6. The Worklist Iterative Algorithm
Worklist  { all blocks, bi }
while (Worklist  Ø)
remove a block b from Worklist
recompute AVAIL(b ) as
AVAIL(bi) = xpred(b) (DEEXPR(x)  (AVAIL(x)  EXPRKILL(x) ))
if AVAIL(b ) changed then
Worklist  Worklist  successors(b )
COMP 512, Fall 2003

7. Iterative Data-flow Analysis
How do we use these results?
Prove that data-flow framework is admissible & rapid
Its just algebra
Most (but not all) global data-flow problems are rapid
This is a property of F
Code up an iterative algorithm
World’s simplest data-flow algorithm
Rely on the results
Theoretically sound, robust algorithm
This lets us ignore most of the other data-flow algorithms in 512
COMP 512, Fall 2003

8. Proliferation of Data-flow Problems
Philosophy
Safety is often formulated as a data-flow problem
Solve problem to prove the necessary pre-conditions
One problem to solve per transformation
Implications
Many passes over the program
Lots of time spent allocating, initializing, & freeing sets
Compute lots of intersections & unions
Desiderata
Solve one data-flow problem
Use it for all transformations
COMP 512, Fall 2003

9. Computing Available Expressions
AVAIL(b) = xpred(b) (DEEXPR(x)  (AVAIL(x)  EXPRKILL(x) ))
where
EXPRKILL(b) is the set of expression killed in b, and
DEEXPR(b) is the set of expressions defined in b and not subsequently killed in b
Initial condition
AVAIL(n0) = Ø, because nothing is computed before n0
The other node’s AVAIL sets will be computed over their preds.
N0 has no predecessor.
COMP 512, Fall 2003

10. Example Transformation: Eliminating unneeded stores
|LIVEOUT| = |variables|
Example
Transformation: Eliminating unneeded stores
e in a register, have seen last definition, never again used
The store is dead (except for debugging)
Compiler can eliminate the store
Data-flow problem: Live variables
LIVEOUT(b) = s  succ(b) UEVAR(s)  (LIVE(s)  VARKILL(s))
LIVEOUT(nf) = Ø
LIVE(b) is the set of variables live on exit from b
VARKILL(b) is the set of variables that are redefined in b
UEVAR(b) is the set of variables used before any redefinition in b
Live analysis is a backward flow problem
Form of f is same as in AVAIL
LIVE plays an important role in both register allocation and the pruned-SSA construction.
COMP 512, Fall 2003 *

11. Example Transformation: Hoisting e defined in every successor of b
|VERYBUSY| = |expressions|
Example
Transformation: Hoisting
e defined in every successor of b
Evaluating e in b produces same result
Saves code space, but shortens no path
Data-flow problem: Very Busy Expressions
VERYBUSY(b) = s  succ(b) UEEXPR(s)  (VERYBUSY(s) - EXPRKILL(s))
VERYBUSY(nf) = Ø
VERYBUSY(b) contains expressions that are very busy at end of b
UEEXPR(b) is the set of expressions used before they are killed in b
EXPRKILL(b) is the set of expressions killed before they are used in b
VERYBUSY expressions is a backward flow problem
Form of f is same as in AVAIL
COMP 512, Fall 2003 *

12. Example Transformation: Global Constant Folding
|CONSTANTS| = |variables|
Example
Transformation: Global Constant Folding
Along every path to p, v has same known value
Specialize computation at p based on v’s value
Data-flow problem: Constant Propagation
Domain is the set of pairs <vi,ci> where vi is a variable and ci  C
CONSTANTS(b) = p  preds(b) fp(CONSTANTS(p))
 performs a pairwise meet on two sets of pairs
fp(x) is a block specific function that models the effects of block p on the <vi,ci> pairs in x
Constant propagation is a forward flow problem
… c-2 c-1 c0 c1 c2 ...
The Lattice C
Form of f is quite different than in AVAIL
COMP 512, Fall 2003 *

13. Example Meet operation requires more explanation
c1  c2 = c1 if c1 = c2, else  (bottom & top as expected)
What about fp ?
If p has one statement then
x  y with CONSTANTS(p) = {…<x,l1>,…<y,l2>…}
then fp(CONSTANTS(p)) = CONSTANTS(p) - <x,l1> + <x,l2>
X  y op z with CONSTANTS(p) = {…<x,l1>,…<y,l2>… >,…<z,l3>…}
then fp(CONSTANTS(p)) = CONSTANTS(p) - <x,l1> + <x,l2 op l3>
If p has n statements then
fp(CONSTANTS(p)) = fn(fn-1(fn-2(…f2(f1(CONSTANTS(p)))…)))
where fi is the function generated by the ith statement in p
COMP 512, Fall 2003
fp interprets p over CONSTANTS

14. Proliferation of Data-flow Problems
If we continue in this fashion,
We will need a huge set of data-flow problems
Each will have slightly different initial information
This seems like a messy way to go …
Desiderata
Solve one data-flow problem
Use it for all transformations
To address this issue, researchers invented information chains
COMP 512, Fall 2003

15. Information Chains A tuple that connects 2 data-flow events is a chain
Chains express data-flow relationships directly
Chains provide a graphical representation
Chains jump across unrelated code, simplifying search
We can build chains efficiently
Four interesting types of chain
Def-Use chains are the most common
COMP 512, Fall 2003

16. Information Chains Example a  5 b  3 c  b + 2 d  a - 2 e  a + b
e  e + c
e  13
def-use chains
d is dead
It has no use
f  2 + e
Write f
COMP 512, Fall 2003 *