from speculative partial redundancy elimination to ...amaral/cascon/cdp04/slides/horsp… ·...
TRANSCRIPT
From Speculative Partial Redundancy Elimination to Speculative Partial Dead Code Elimination
Nigel Horspool, University of Victoria, CanadaDavid Pereira, University of Victoria, Canadain collaboration with
Bernhard Scholz, University of Sydney, AustraliaJens Knoop, Vienna University of Technology, Austria
Slide 1
Synopsis
• This is work in progress.• Some experimental results with SPRE were reported in proceedings
of the Conference on Languages, Compilers, and Tools for Embed-ded Systems (LCTES), June 2004.
• We are exploring ideas to generalize SPRE and to make it a practical approach for use in JIT compilers.
Slide 2
From PRE to SPRE
Partial Redundancy Elimination
... is a generalization of code motion (Morel and Renvoise, 1979)
...= a+b a =
...= a+b
Slide 3
From PRE to SPRE
Partial Redundancy Elimination
... is a generalization of code motion (Morel and Renvoise, 1979)
...= a+b a =
...= a+b
t1 = a+b... = t1
a = ...t1 = a+b
... = t1
Slide 3
From PRE to SPRE
Partial Redundancy Elimination
... is a generalization of code motion (Morel and Renvoise, 1979)
1000 1000
500 500500 500
10001000
...= a+b a =
...= a+b
t1 = a+b... = t1
a = ...t1 = a+b
... = t1
1000 1000
1000
Slide 3
But... Partial Redundancy Elimination
... is also very conservative. An expression e can be inserted at a point P only if every path starting from P uses e. This restriction guarantees:
• safety, and• optimality (no more evaluations of the expression than before).
...= a+b
Slide 4
But... Partial Redundancy Elimination
... is also very conservative. An expression e can be inserted at a point P only if every path starting from P uses e. This restriction guarantees:
• safety, and• optimality (no more evaluations of the expression than before).
...= a+b ... = t1
t1 = a+b
?
Slide 4
But... Partial Redundancy Elimination
... is also very conservative. An expression e can be inserted at a point P only if every path starting from P uses e. This restriction guarantees:
• safety, and• optimality (no more evaluations of the expression than before).
...= a+b ... = t1
t1 = a+b
?10000
11
1
10000
1
Slide 4
But... Partial Redundancy Elimination
... is also very conservative. An expression e can be inserted at a point P only if every path starting from P uses e. This restriction guarantees:
• safety, and• optimality (no more evaluations of the expression than before).
...= a+b ... = t1
t1 = a+b
?10000
11
1
10000
1
Slide 4
Speculative PRE
• An evaluation of e can be inserted anywhere as long as it is safe to do so,
Slide 5
Speculative PRE
• An evaluation of e can be inserted anywhere as long as it is safe to do so, and
• we speculatively compute e in the hope that the value will be useful later.
Slide 5
Speculative PRE
• An evaluation of e can be inserted anywhere as long as it is safe to do so, and
• we speculatively compute e in the hope that the value will be useful later.
• Using probabilistic information (from execution profiles or elsewhere), the optimality goal becomes minimization of the expected number of evaluations.Cai & Xue [CGO 2003] and Scholz, Horspool & Knoop [LCTES 2004] have presented SPRE algorithms which find optimal solutions.We prefer the LCTES 2004 approach because the objective function can combine several different cost measures.
Slide 5
SPRE Example
..=a+b
a = ... b = ...
..=a+b
5
1 3
5
13
10
1
#evals=15; #occurrences=2
Slide 6
SPRE Example – optimized for time
...= h
a =...h = a+b
b =...h = a+b h = a+b
...= h
1 1 3
10
5
13
#evals=5; #occurrences=3
5
..=a+b
a = ... b = ...
..=a+b
5
1 3
5
13
10
1
#evals=15; #occurrences=2
Slide 7
SPRE Example – optimized for space+time
...= h
a = ... b = ...h = a+b
..=a+b
1 1 3
10
5
13
105
#evals=8; #occurrences=2
..=a+b
a = ... b = ...
..=a+b
5
1 3
5
13
10
1
#evals=15; #occurrences=2
Slide 8
Optimal SPRE
• For each expression, our algorithm maps the optimal SPRE problem to a network flow problem.
• Efficient techniques exist to solve for maximum flow.• The cost function is a linear combination of:
– any static property (size is a useful measure),– execution frequency times any static property
Slide 9
Issues with SPRE and proposed solutions
1. Register pressure
Usually we have too many expressions and too few registers. How can we handle that?
Slide 10
Issues with SPRE and proposed solutions
1. Register pressure
Usually we have too many expressions and too few registers. How can we handle that?
Proposal:
Incorporate a measure of register pressure into the cost function.E.g., lifetime of the value (distance from place where computed to the place where used) can be added into the objective function.Cost of using a saved value =
a × size of the expression +frequency × (b × execution time of original expression +
c × distance from top of block)and there are similar costs elsewhere for keeping the value alive.
Slide 10
Issues with SPRE and proposed solutions
2. Computational cost
Only one expression at a time is analyzed. (It’s not a bit-vector prob-lem.)
Solutions to be tried
• Reduce the size of the constructed network by– applying some basic transformation techniques, and– discarding low frequency regions of the network.
• Incremental analysis (reusing a previous analysis).
Slide 11
Issues with SPRE and proposed solutions
3. Non-reversibility of code transformation
= a+b = h
I IIh = a+b
Slide 12
Issues with SPRE and proposed solutions
3. Non-reversibility of code transformation
• Whether I or II is better depends on the objective function; but we cannot get from II to III using the standard PRE transformations.If the original program is like II, we may want to get to III (to reduce register pressure, to reduce size, ...)
= a+b = a+b = h
I II IIIh = a+b
Slide 12
Partial Dead Code Elimination (PDE)
An expression e is not used on all subsequent execution paths ...
e = a+b
= e a =
a =
Slide 13
Partial Dead Code Elimination (PDE)
An expression e is not used on all subsequent execution paths ...
• we can push the evaluation later to point(s) where the expression is needed on all subsequent paths.(This is assignment sinking.)
e = a+b
= e a = = e a =
e = a+ba =a =
Slide 13
From PDE to Speculative PDE
• A misnomer because there is no speculation involved.• However, it makes sense to associate costs with expression evalua-
tions which depend on the execution frequency.• Assignment sinking reduces register pressure.• Assignment sinking may increase program size.• Note that optimal solutions will not be found efficiently because of
second order effects – placement of one expression affects the place-ment of another.See example ...
Slide 14
2nd order effects in SPDE
x = a+ba = c+d
= x= a
= a
5K 10K
5K
3K 3K
5K
Slide 15
2nd order effects in SPDE
x = a+ba = c+d
= x= a
= a
5K 10K
5K
3K 3K
5K
a = c+d
x = a+ba = c+d= x
a = c+d= a
= a
5K 10K
5K
3K 3K
5KA suboptimal placement of a=c+d must be made before placing x=a+b and achieving the globally optimal solution.
Slide 16
Mapping SPDE to SPRE
e = a+b
= ea =
= e = e
Slide 17
Mapping SPDE to SPRE
• Insert the definition of a variable before each use; then run SPRE to remove redundant evaluations and move them to optimal points.
• If more than one definition reaches a use, we insert the definitions before the point where the control flow paths merge.
• Note: we are ignoring the second-order effects.
e = a+b
= ea =
= e = e
e = a+b
e = a+b = e
a = = ee = a+b = e
Slide 17
Summary
• Execution profiles permit much better results to be obtained from PRE and PDE optimizations.
• Our cost metric model permits an appropriate trade-off between (esti-mates of)– execution time,– space,– power consumption, and– register pressure.
• Only an implementation in a real compiler will show how well it will work in practice.
Slide 18
THANK YOU!
ANY QUESTIONS?