advanced compiler techniques

Advanced Compiler Techniques

LIU Xianhua

School of EECS, Peking University

Partial Redundancy Elimination

2

REVIEW Foundations

Data Flow Framework Lattice-Theoretic Formulation Meet-Over-Paths Solution

Extensions Other DFA Methods

“Advanced Compiler Techniques”

3

REVIEW


Available Expressions Analysis

Live Variables Analysis

≤ is ⊆, ∧ is ∩ ≤ is ⊇, ∧ is ∪

4

REVIEW

All possible assignments

All safe assignments

All fixed point solutions

Meet Over Paths Assignment

Maximum Fixed Point

Least Fixed Point

∀i , Ini = Outi = ⊤

∀i , Ini = Outi = ⊥“Advanced Compiler Techniques”

5

REVIEW

Entry B

Since f(x ∧ y) ≤ f(x) ∧ f(y), it is as if we addednonexistent paths, but we’re safe.

f

OUT = x

OUT = y

IN = x∧y

OUT = f(x∧y)

In MFP, Values x and yget combined too soon. f(x)

f(y)

MOP considers pathsindependently andand combines at the last possible moment.

OUT = f(x) ∧ f(y)


6

Summary of DFA Methods

Method Speed Simple?

Structure

Both Way?

Graph Class

Iterative O(n2) Simple No Yes AllInterval O(n2) Middle Yes Yes ReducibleBalance

TreeO(nlog

n)Complicated

Yes No Reducible

Path Comp.

O(nlogn)

Middle Semi Yes Reducible

Node List O(nlogn)

Middle No Yes Reducible

Balance Path

O(nα(n,n))

Complicated

No ? Reducible

Grammar

n Middle Yes Yes L(Grammar)

High Level

n Simple Yes Yes Parse Trees



Outline

• Forms of redundancy– global common sub-expression– loop invariant– partial redundancy expression

• Lazy Code Motion Algorithm– A set of four analysis

7


Role of PRE

• Goal: Minimize the number of expression evaluations.– Keep the value of evaluation in a

temporary variable and use it later.• Sources of redundancy:– Global common sub-expressions– Loop-invariant computations– True partial redundancy: an expression

is sometimes available, sometimes not8

9

Partial redundancy elimination One of the most complex dataflow

analysis Subsumes common sub-expression

elimination and loop invariant code motion

Originally proposed in 1979 by Morel and Renvoise, Used a bi-directional dataflow analysis

Reformulated by Knoop, Rüthing and Steffen in 1992, Uses a backward dataflow analysis followed by a forward analysis

We will discuss this latter formulation“Advanced Compiler Techniques”

10

Convention

• Throughout, assume that neither argument of an expression x+y is modified unless we explicitly assign to x or y.

• And of course, we assume x+y is the only expression anyone would ever want to compute.

• Can easily extend this to multiple expressions by using a bit vector lattice. “Advanced Compiler Techniques”


Example: Global CSE

• A common expression may have different values on different paths.

• On every path reaching p,– expression x+y has been computed– x, y not overwritten after the expression

a = x+y b = x+y

c = x+y

t = x+ya = t

t = x+yb = t

c = t

11

a=x+y

d=x+y

a=x+y

x=7

d=x+y

a=x+y x=7f=x+y

d=x+y


Example:Loop-Invariant Code Motion

• Given an expression (x+y) inside a loop,– does the value of x+y change inside the loop?– is the code executed at least once?

t = x+ya = x+y

a = t

12


Example: True Partial Redundancy

• Can we place calculations of x+y such that no path re-executes the same expression?

a = x+y

b = x+y

t = x+ya = t t = x+y

b = t

13

14

Modifying the Flow Graph

• We could:1. Add a new block along an edge.

Only necessary if the edge enters a block with several predecessors.

2. Duplicate blocks so an expression x+y is evaluated only along paths where it is needed.


15

Example: Node Splitting

t = x+y

= t

= x+y

= x+y

= x+y

t = x+y



Can All Redundancy Be Eliminated?

• Critical edges– source basic block has multiple successors– destination basic block has multiple

predecessors16


Code Duplication

17


Problem With Node-Splitting

• Can exponentiate the number of nodes.

• Our PRE algorithm needs to move code to new blocks along edges, but will not split blocks.

• Convention: All new instructions are either inserted at the beginning of a block or placed in a new block.

18


Lazy Code Motion Problem

• Desired properties of a PRE algorithm– All redundant computations of

expressions that can be eliminated without code duplication are eliminated.

– The optimized program does not perform any computation that is not in the original program execution.

– Expressions are computed at the latest possible time.

19


Full Redundancy

• Full redundancy at p: expression a+b redundant on all paths– cutset: nodes that separate entry from p– cutset contains calculation of a+b– a, b, not redefined

20


Partial Redundancy

• Partial redundancy at p: redundant on some but not all paths– Add operations to create a cutset containing

a+b– Note: Moving operations up can eliminate

redundancy 21


The Plan

1. Determine for each expression the earliest place(s) it can be computed while still being sure that it will be used.

2. Postpone the expressions as long as possible without introducing redundancy.– We trade space for time --- an

expression can be computed in many places, but never if it is already computed.

22


The Guarantee

• No expression is computed at a place where it its value might have been computed previously, and preserved instead.– Even along a subset of the possible

paths.

23

24

The Plan – (2)3. Determine those places where it is really necessary to store x+y in a temporary rather than compute it when needed.

Example: If x+y is computed in only one place.


25

More about the plan Don’t introduce/insert new operations

didn’t exist originally: Anticipate the range of code motion Eliminate as many redundant

calculations of an expression as possible, without duplicating code

Move it up as early as possible Delay computation as much as possible

to minimize register Lifetimesmove it down unless it creates redundancy (lazy code motion) Remove temporary assignment



More About the Plan

• We use four data-flow analysis, in succession, plus some set operations on the results of these analysis.– Anticipated Expressions– Available Expressions– Postponable Expressions– Used Expressions

• After the first, each analysis uses the results of the previous ones.

26


Assumptions

• Assume every statement is a basic block– Only place statements at the beginning

of a basic block– Add a basic block for every edge that

leads to a basic block with multiple predecessors

27


Anticipated Expressions

• Expression x+y is anticipated at a point if x+y is certain to be evaluated along any computation path, before any recomputation of x or y.

• Copies of an expression must be placed only at program points where the expression is anticipated.– The earlier an expression is placed, the

more redundancy can be removed28

29

Example: Anticipated Expressions

= x+y = x+y

= x+y

x+y is anticipatedhere and could becomputed now ratherthan later.

= x+y

x+y isanticipatedhere, but isalso available.No computa-tion is needed.



Computing Anticipated Expressions

• Use(B) = set of expressions x+y evaluated in B before any assignment to x or y.

• Def(B) = set of expressions one of whose arguments is assigned in B.

30


Computing Anticipated Expressions

• Direction = backwards.• Join (or Meet) = intersection.• Boundary condition: IN[exit] = ∅.• Transfer function: IN[B] = (OUT[B] – Def(B)) ∪ Use(B)

31

32

Example: Anticipated Expressions

= x+y

= x+y

Anticipated

Backwards; Intersection; IN[B] = (OUT[B] – Def(B)) ∪ Use(B)“Advanced Compiler Techniques”

33

“Available” Expressions

• Modification of the usual AE.• x+y is “available” at a point if

either:1. It is available in the usual sense; i.e., it

has been computed and not killed, or2. It is anticipated; i.e., it could be

available if we chose to precompute it there.


34

“Available” Expressions

• x+y is in Kill(B) if x or y is defined, and x+y is not recomputed later in B (same as previously).

• Direction = Forward• Meet = intersection.• Transfer function:

OUT[B] = (IN[B] ∪ INANTICIPATED[B]) – Kill(B)


35

Earliest Placement x+y is in Earliest[B] if it is anticipated at

the beginning of B but not “available” there. That is: when we compute anticipated

expressions, x+y is in IN[B], but When we compute “available”

expressions, x+y is not in IN[B]. I.e., x+y is anticipated at B, but not

anticipated at OUT of some predecessor.


36

Example: Available/Earliest

= x+y

= x+y

Anticipated

“Available”

Earliest = anticipatedbut not available

Forward; Intersection; OUT[B] = (IN[B] ∪ INANTICIPATED[B]) – Kill(B)“Advanced Compiler Techniques”

37

Postponable Expressions

• Now, we need to delay the evaluation of expressions as long as possible, but …

1. Not past the use of the expression.2. Not so far that we wind up computing

an expression that is already evaluated.

• Note viewpoint: It is OK to use code space if we save register use.



Example

t = b+c

a = t

d = t

38


Example

t = b+c

t = b+ca = t

d = t

39

40

Postponable Expressions – (2) x+y is postponable to a point p if on

every path from the entry to p:1. There is a block B for which x+y is in

earliest[B], and2. After that block, there is no use of x+y.


41

Postponable Expressions – (3) Computed like “available” expressions,

with two differences:1. In place of killing an expression

(assigning to one of its arguments): Use(B), the set of expressions used in block B.

2. In place of INANTICIPATED[B]: earliest[B].


42

Postponable Expressions – (4) Direction = forward. Meet = intersection. Transfer function:OUT[B] = (IN[B] ∪ earliest[B]) – Use(B)


43

Example: Postponable Expressions

= x+y = x+y

= x+y

Earliest

Postponable

Three places tocompute x+y

Forward; Intersection; OUT[B] = (IN[B] ∪ earliest[B]) – Use(B)“Advanced Compiler Techniques”

44

Latest Placement

• We want to postpone as far as possible.

• How do we compute the “winners” – the blocks such that we can postpone no further?

• Remember – postponing stops at a use or at a block with another predecessor where x+y is not postponable.


45

Latest[B]

• For x+y to be in latest[B]:1. x+y is either in earliest[B] or in

INPOSTPONABLE[B].• I.e., we can place the computation at B.

2. x+y is either used in B or there is some successor of B for which (1) does not hold.• I.e., we cannot postpone further along all

branches.


46

Example: Latest

= x+y = x+y

= x+y

EarliestOr Postponableto beginning

UsedOr has a suc-cessor not red.

Latest =Blue and red.


47

Final Touch – Used Expressions We’re now ready to introduce a

temporary t to hold the value of expression x+y everywhere.

But there is a small glitch: t may be totally unnecessary. E.g., x+y is computed in exactly one

place.


48

Used Expressions An expression is used at point p if There exists a path leading from p that

uses the expression before the value is reevaluated.

Essentially liveness analysis for expressions rather than for variables.


49

Example: Used

= x+y = x+y

= x+y

Recall: Latest

Used

Backwards; Union; IN[B] = (OUT[B] ∪ e-used[B]) – Latest(B)“Advanced Compiler Techniques”

50

Used Expressions – (2)

• used[B] = expressions used along some path from the end of B.

• Direction = backward.• Meet = union.• Transfer function:

IN[B] = (OUT[B] ∪ e-used[B]) – Latest(B)– e-used = “expression is used in B.”


51

Rules for Introducing Temporaries1. If x+y is in both Latest[B] and OUTUSED[B],

introduce t = x+y at the beginning of B.2. If x+y is used in B, but either

1. Is not in Latest[B] or2. Is in OUTUSED[B],replace the use(s) of x+y by uses of t.


52

Example:Where is a Temporary Used?

= x+y = x+y

= x+y

Recall: Latest

Recall OUTUSED

Create temp-orary here

Use it here

But not here ---x+y is in Latest andnot in OUTUSED


53

Example: Here’s Where t is Used

= x+y t = x+y = t

= t

t = x+y



Summary

• Cannot execute any operations not executed originally– Pass 1: Anticipation: range of code motion

• Eliminate as many redundant calculations of an expression as possible, without duplicating code– Pass 2: Availability: move it up as early as

possible• Delay computation as much as

possible to minimize register lifetimes– Pass 3: Postponable: move it down unless it

creates redundancy (lazy code motion)• Pass 4: Remove temporary

assignment54

55

Data Flow Analysis of PRE


56

Data Flow Analysis of PRE


57

Algorithm of Lazy Code Motion INPUT: A flow graph for which e_useB and e_killB

have been computed for each block B. OUTPUT: A modified flow graph satisfying the four

lazy code motion conditions. METHOD:

Insert an empty block along all edges entering a block with more than one predecessor

Find anticipated[B] .in for all blocks B Find available[B] .in for all blocks B Compute the earliest placements for all blocks

B Find postponable[B].in for all blocks B Compute the latest placements for all blocks B Find used[B] .out for all blocks B“Advanced Compiler Techniques”

58

Algorithm of Lazy Code Motion METHOD:

8. For each expression, say x+y, computed by the program, do the following:

Create a new temporary, say t, for x + y. For all blocks B such that x + y is in latest[B]∩

used[B].out, add t = x +y at the beginning of B.

For all blocks B such that x + y is ine_use B ∩ (┐latest[B] ∪ used.out[B] )

replace every original x + y by t.


59

Example


60

More about PRE Don’t need heuristic

Dhamdhere, Drechsler-Stadel, Knoop,et.al. use restricted flow graph or allow edge placements.

Data flow can be separated into unidirectional passes Dhamdhere, Knoop, et. al.

Improvement still tied to accuracy of computational model Assumes performance depends only on the number of

computations along any path. Ignores resource constraint issues: register alloc., etc. Knoop, et.al. give “earliest” and “latest” placement algorithms

which begin to address this. Further issues:

more than one expression at once, strength reduction, redundant assignments, redundant stores

With GVN,SSA… “Advanced Compiler Techniques”


Next Time

• Homework– 9.5.1 ， 9.5.2

• Loops– Dragon Book: §9.6

61

advanced compiler techniques

Documents