Spring 2014Jim Hogg - UW - CSE - P501R-1 CSE P501 – Compiler Construction Available Expressions...

Spring 2014 Jim Hogg - UW - CSE - P501 R-1

CSE P501 – Compiler Construction

Available Expressions

Dataflow Analysis

Aliasing


The Story So Far…

Redundant expression elimination Local Value Numbering (LVN) Super-local Value Numbering (SVN)

Extends LVN to EBBs SSA-like namespace

Dominator Value Numbering (DVN)

All of these propagate along forward edges

None are global In particular, none can handle back edges and

loops


Dominator Value Numbering

m0 = a0 + b0

n0 = a0 + b0

A

p0 = c0 + d0

r0 = c0 + d0

Bq0 = a0 + b0

r1 = c0 + d0

C

e0 = b0 + 18s0 = a0 + b0

u0 = e0 + f0

De1 = a0 + 17t0 = c0 + d0

u1 = e1 + f0

E

e2 = Φ(e0,e1)u2 = Φ(u0,u1)v0 = a0 + b0

w0 = c0 + d0

x0 = e2 + f0

F

r2 = Φ(r0,r1)y0 = a0 + b0

z0 = c0 + d0

G

Most sophisticated algorithm so far

Still misses some opportunities Can’t handle loops

Missed opportunities


Goal: use dataflow analysis to find CSEs that span basic blocks

Idea: calculate available expressions at beginning of each block (rather than just the Value-Numbers for variables)

Having found an expression that is already available, there's no need to re-evaluate it: use a copy instead

Available Expressions

Available Expressions: It's Simple!


a=b+cd=e+ff=a+c

g=a+c g=a+dh=b+c

j=a+b+c+d

b+c is available here

• b+c was calculated earlier• neither b nor c has been assigned-to

since• so replace h=b+c with h=a

• No Value Numbers (super-scripts)• ie: trying to work out whether two variables hold

same value• No SSA Numbers (sub-scripts)

• ie: recording the life or instantiation of each variable


“Available” and Other Terms

An expression e is defined at point p in the flowgraph if its value is computed at p

Sometimes called definition site, or simply "def" eg: x = a+b ; expression a+b is defined here

An expression e is killed at point p if one of its operands is defined at p

Sometimes called kill site, or simply "kill" eg: x = a+b ; def site b = 7 ; kill site ; kills every expression involving b !

An expression e is available at point p if every path leading to p contains a prior definition of e and e is not killed between that definition and p

Simply: an available expression is one you don't need to re-calculate

Available Expressions - Intuition


=a+b

a+b?

=a+b

=a+b

a+b?

=a+b

a+b?

a=

=a+b

a+b?

a+b must reach a+b? So, every path from start to a+b? must include a def for a+b. Any assignment to a or b kills that available expression, throughout the procedure!

Available Expressions: Flowgraph


a=b+cd=e+ff=a+c

g=a+c g=a+dh=b+c

j=a+b

Number the Expressions


a=b+c 1d=e+f 2f=a+c 3

g=a+c 4

g=a+d 5h=b+c 6

j=a+b 7

• Start by assigning (arbitrary) numbers to every expression in the function

• Pay no attention to what each expression is, just number it!

• Implementation: a map between expression number and location - eg, expression #6 = instruction#3 in basic-block #4

def & kill for each Instruction



g=a+c 4

g=a+d 5h=b+c 6

j=a+b 7

{1}{2}{3}

{3,4,5,7}{5}{}

Eg: a = b + c• defs the expression b+c• kills every expression that

uses a

killdef

Summarize DEF & KILL for Basic Block



g=a+c 4

g=a+d 5h=b+c 6

DEF= {}foreach instruction DEF= (DEF geni ) - killi

KILL = {}foreach instruction KILL = killi

{1}{2}{3}{1,2}

{3,4,5,7}{5}{}{3,4,5,7}

killdef

def and kill ~ instructionDEF and KILL ~ basic block

j=a+b 7

Union all the defs: {1,2,3}. Remove any which appear in KILL => {1,2}

Summarize DEF & KILL for Flowgraph



g=a+c 4

g=a+d 5h=b+c 6

{1}{2}{3}{1,2}

{3,4,5,7}{5}{}{3,4,5,7}

killdef

{5}{6}{5,6}

{}{}{}

{4}{4}

{}{}

j=a+b 7


Available Expression Sets For each block b, define

DEF(b) – the set of expressions defined in b and not subsequently killed in b

ie: defined in b and survives to its end can construct this by inspecting b in isolation - never changes

KILL(b) – the set of all expressions in the entire procedure that is killed in b

can construct this by inspecting b in isolation - never changes

AVAIL(b) – the set of expressions available on entry to b find by solving a set of equations

Implementation: assign a number to each expression and track its availability via one bit in a (large) bit-vector representing the set of all expressions in the function

Spring 2014 R-14

Computing Available Expressions

preds(b) is the set of b’s predecessors in the flowgraph works for all flows, including loops defines a system of simultaneous equations – a dataflow

problem

AVAIL(b) = DEF(p) ( AVAIL(p) - KILL(p) ) p preds(b)

b

p3p2p1 predecessors

AVAIL(b)

GEN(p)

KILL(p)

AVAIL(p)

AVAILb = Intersectp DEFp (AVAILp - KILLp)


Computing Available Expressions

foreach block b { set AVAILb = {all expressions in function} = U}

worklist = {all blocks in function}

while (worklist {}) remove a block b from worklist recompute AVAILb

if AVAILb changed worklist = = successorsb

}}

Given DEFb and KILLb for each basic block, b, in the procedure:


Name Space?

In previous value-numbering algorithms, we used an SSA-like renaming to keep track of versions

In global dataflow problems, we use the original namespace we require that a+b have the same value along all paths to its use if a or b is updated along any path to its use, then a+b has the

'wrong' value, so must recalculate its value so original names are exactly what we want

KILL captures when an expression becomes no longer "available"


Global CSE using Available Expressions

Phase I Number each expression in procedure For each block b, compute DEFb and KILLb - once off Initialize AVAILb = {all expressions in procedure} = U For each block b, compute AVAILb, by iterating until fixed

point

Phase II For each block b, value-number the block starting with

AVAILb

Replace expressions in AVAILb with references to the previously computed values

Also called "Global Redundancy Elimination" or GRE


Comparing Algorithms

m = a + bn = a + b

A

p = c + dr = c + d

Bq = a + br = c + d

C

e = b + 18s = a + bu = e + f

De = a + 17t = c + du = e + f

E

v = a + bw = c + dx = e + f

F

y = a + bz = c + d

G

LVN – Local Value Numbering SVN – Superlocal Value

Numbering DVN – Dominator-based Value

Numbering GRE – Global Redundancy

Elimination


Comparing Algorithms (2)

LVN <= SVN <= DVN form a strict hierarchy later algorithms find a superset of previous information

Global Redundancy Elimination, via Available Expressions, finds a different set

Discovers e+f in F (computed in both D and E) Misses identical values if they have different names

eg: a+b and c+d when a=c and b=d Value Numbering catches this

e = b + 18s = a + bu = e + f

De = a + 17t = c + du = e + f

E

v = a + bw = c + dx = e + f

F


Scope of Analysis

Larger context (EBBs, regions, global, inter-proc) may help

More opportunities for optimizations

But not always

Introduces uncertainties about flow of control Usually only allows weaker analysis Sometimes has unwanted side effects

Can create additional pressure on registers, for example

Code Replication

Sometimes replicating code increases opportunities

modify code to create larger regions with simple control flow

Two examples Cloning Inline substitution



A

B C

D E

F

G

m = a + bn = a + bA

p = c + dr = c + d

B q = a + br = c + d

C

e = b + 18s = a + bu = e + f

De = a + 17t = c + du = e + f

E

v = a + bw = c + dx = e + f

F

y = a + bz = c + d

G

v = a + bw = c + dx = e + f

F

y = a + bz = c + d

Gy = a + bz = c + d

G

Original

Cloned

Cloning: Before & After

Even LVN can optimize these larger basic blocksLarger code size => increased I-cache pressure

Inline Substitution ("inlining")

Global optimizer must assume the callee can modify all reachable data:

In MiniJava, all fields of all objects In C/C++, additionally all "global" data

So the call kills many available expressions Must save/restore caller registers across call Calling the function imposes its own overhead


Calling a function can be expensive!

• Inlining: replace each call with a copy of the callee

• Introduces more opportunities for optimization

Solution

Inline Substitution - "inlining"

Eliminates call overhead Opens opportunities for more

optimizations Can be applied to large method bodies

too Aggressive optimizer will inline 2 or more

deep Increases total code size With care, is a huge win for OO code Recompile if caller or callee changes!


class C { int x; int getx() { return x; }}

class X { void f() { C c = new C(); int total = c.getx() + 42; }}

class X { void f() { C c = new C(); int total = c.x + 42; }}

Class with trivial getter

Method f calls getx

Compiler inlines body of getx into f

"Available Expressions" is a first example of dataflow analysis It supports the optimization called "Global Redundancy Elimination", or GRE

Many similar problems can be expressed in same framework

No limit to the number of execution paths thru a function No limit to the length of an execution path And yet, Dataflow Analysis infers a finite number of facts about the function Dataflow Analysis does not distinguish among the paths taken to any point

eg: it assumes both arms of an IF-THEN-ELSE can be taken We then use these facts to transform and optimize the IR

Example facts about a single function Variable x has the constant value 42 at every point At point p, variable x has same value as variable y At point p, value of x could have been defined only at point q At point p, the value of x is no longer required


Dataflow Analysis

Dataflow Equations - Overview


• Available Expressions• AVAILINb = Intersectp DEFp ( AVAILINp - KILLp )

• Live Variables• LIVEINb = USEb ( LIVEOUTb - DEFb )

• Reaching Defs• REACHESb = Unionp DEFOUTp ( REACHESp SURVIVESp )

• Anticipatable (Very Busy) Expressions• ANTICb = Intersects USEDs ( ANTICs - KILLEDs )

• Generic• OUTb = GENb ( INb - KILLb )


Dataflow Analysis

Set of techniques for compile-time reasoning about runtime values

Need to build a graph Trivial for basic blocks Flowgraph for whole-function (global) analysis Callgraph for whole-program analysis

Limitations Assumes all paths are taken (eg: both arms of IF-THEN-ELSE) Infers facts about a function, rather than actual runtime values

eg: x+y is redundant Arrays – treats array as one variable

eg: don't know, in general, whether a[i] == a[j] Pointers – difficult, expensive to analyze

eg: *p = 1; *q = 2; return *p; // same as return 1?

R-28

Same analysis we did earlier to eliminate redundant expressions

Spring 2014

b

p3p2p1 predecessors

AVAILb

DEFp

KILLp

AVAILp

AVAILb = Intersectp DEFp ( AVAILp - KILLp )

Recap: Available Expressions

Spring 2014 R-29

Characterizing Dataflow Analysis

All dataflow algorithms involve sets of facts about each block b

INb – facts true on entry to b OUTb – facts true on exit from b GENb – facts created and not killed in b KILLb – facts killed in b

These are related by the equationOUTb = GENb ( INb – KILLb )

Solve this iteratively for all blocks Sometimes facts propagate forward (eg: available expressions) Sometimes facts propagate backward (eg: reaching defs)

bGENb

INb

OUTbKILLb


A variable v is live at point p if there is any path from p to a use of v along which v is not redefined

ie: a variable is live here if some later code uses its value there

Some uses:

Register allocation – only live variables need a register Only live variables need be stored back to memory Detect use of uninitialized variables - how? Improve SSA construction – only need Φ-function for

variables that are live in a block (later)

Live Variables (or "liveness")

Liveness Analysis Sets

For each block b, define the sets:

USEb = variables used (ie, read-from) in b before any def

DEFb = variables defined (ie, assigned-to) in b & not subsequently killed in b

INb = variables live on entry to b

OUTb = variables live on exit from b


Liveness - Intuition


=x x is "livein"

B

x=

x is "liveout"

B

=x

x=

x is not "liveout"

B

x=

DEFB = {x}

USEC = {x}

USEB = {x}

DEFB = {x}

C

CDEFC = {x}

Liveness Equations

Set INb = OUTb = {} Update IN and OUT until no

change "backwards" dataflow analysis

Spring 2014 T-33

OUTb = Unions INs

INb = USEb ( OUTb - DEFb )

b

s2s1 successors

OUTb

INs1INs2

USEb

DEFb

INb

Liveness Calculation


INb = USEb (OUTb – DEFb) OUTb = Unions INs

1: a = 0

2: b = a + 1

3: c = c + b

4: a = b * 2

5: a < N

6: return c

block USE DEF

1 - a

2 a b

3 b c c

4 b a

5 a -

6 c -

• Work backwards from 6 to 1




1: a = 0

2: b = a + 1

3: c = c + b

4: a = b * 2

5: a < N

6: return c

block USE DEF OUT IN

1 - a a c c

2 a b b c a c

3 b c c b c b c

4 b a a c b c

5 a - c a c

6 c - - c

• Work backwards from 6 to 1• Note c is livein for block 1 -

uninitialized!




1: a = 0

2: b = a + 1

3: c = c + b

4: a = b * 2

5: a < N

6: return c

block USE DEF OUT IN OUT

IN

1 - a a c c a c c

2 a b b c a c b c a c

3 b c c b c b c b c b c

4 b a a c b c a c b c

5 a - c a c a c a c

6 c - - c - c

• Work backwards from 6 to 1• Only change in iteration 2 - a is ivein for

block 5• Stops changing after 2 iterations




1: a = 0

2: b = a + 1

3: c = c + b

4: a = b * 2

5: a < N

6: return c

block USE DEF OUT IN OUT

IN

1 - a a c c a c c

2 a b b c a c b c a c

3 b c c b c b c b c b c

4 b a a c b c a c b c

5 a - c a c a c a c

6 c - - c - c

• Work backwards from 6 to 1• Stops changing after 2

iterations


Alternate Liveness Equations

Many problems have more than one formulation

Different books use different sets:

USED[b] – variables used in b before being defined in b

NOTDEF[b] – variables not defined in b LIVE[b] – variables live on exit from b

Equation LIVE[b] = ssucc(b) USED[s] ( LIVE[s] NOTDEF[s] )


A definition of variable v at L1 reaches instruction at L2 if that instruction uses v and there is a path from L1 to L2 that does not re-define v

Use:

Find all possible defs for a variable in an expression - great debugger plugin when looking for 'culprit'

Reaching Defs


Equations for Reaching Defs

Sets DEFOUTb – set of defs in b that reach the end of b

SURVIVEDb – set of all defs not killed by a re-def in b

REACHb – set of defs that reach b

Equation

REACHb = Unionp DEFOUTp ( REACHp SURVIVEDp )


Also known as "Very Busy" Expressions

Expression x+y is anticipated at point p if all paths from p eventually compute x+y, using

values of x and y as they exist at p

Use: Code hoisting – move x+y to p reduces code size; no effect on execution time

Anticipated Expressions


Equations for: Anticipated Expressions

Sets

USEDb – expressions used in b before they are killed KILLEDb – expressions def'd in b before they

are used ANTICb – anticipated expressions on exit from

b

Equation

ANTICb = Intersects USEDs ( ANTICs - KILLEDs )

Dataflow Equations - Recap


• Available Expressions

• AVAILINb = Intersectp DEFp ( AVAILINp - KILLp )

• Live Variables

• LIVEINb = USEb ( LIVEOUTb - DEFb )

• Reaching Defs

• REACHESb = Unionp DEFOUTp ( REACHESp SURVIVESp )

• Anticipated Expressions

• ANTICb = Intersects USEDs ( ANTICs - KILLEDs )

• Generic

• OUTb = GENb ( INb - KILLb )


Efficiency of Dataflow Analysis

The algorithms eventually terminate but reduce time-needed by picking a good order to visit

nodes in the flowgraph depends on how information flows

Forward problems – reverse post-order Backward problems - post-order

Using Dataflow Facts

Some possible Tranformations/Optimizations ...


CSE Elimination

x+y is defined at L1 and available at L2 ie: x nor y is re-defined between L1 and

L2


L1: = x+y t = a

L2: = t

L1: = x+y

L2: = x+y

before after

Save calculation into temp t

Use t, rather than re-calculate

• Analysis: Available Expressions• Code runs faster by not re-calculating

x+y

Constant Prop.

c is a constant a reaches L2 (a is not re-defined between L1

and L2)


L1: a = c

L2: = c

L1: a = c

L2: = a

before after

Propagate c, not a

• Analysis: Reaching Defs• Code runs faster because c is embedded into the

instruction

Copy Prop. x is a variable a reaches L2 (a is not re-defined between L1 and

L2), and is the only def of a to reach L2


L1: a = x

L2: = x

L1: a = x

L2: = a

before after

Propagate x, not a

• Analysis: Reaching Defs• Code runs faster because c is embedded into the

instruction

Copy Prop. Tradeoffs

Downside: can lengthen lifetime of variable x => more register pressure or memory traffic thru spilling not worth doing if only reason is to eliminate copies – let the

register allocate deal with that

Upside: may expose other optimizations. Eg:


a = y + zu = yc = u + z

a = y + zu = yc = y + z

before

after

Now reveals CSE y+z

Dead Code Elimination (DCE)

a is dead after L1 statement at L1 has no side-effects (output,

exceptions, etc)


L1: a = x

before after

Delete statement at L1

• Analysis: Liveness• Code runs faster because one less

statement

Aliasing = more than one name can refer to the same memory location

Call-by-reference parameters eg: calc(C c1, C c2) - c1 might point to same object as c2

Address-taken variables eg: int* p = &x - so x and *p refer to the same memory location

Expressions involving subscripts Without knowing specific value of i, a[i] might refer to any

element of a

Aliasing is the enemy of optimization


Aliasing

Aliases vs Optimizations

Example:p.x = 5; q.x = 7; a = p.x;

Does reaching-defs show that the p.x reaches a?

(Or: do p and q refer to the same variable/object?)

(Or: can p and q refer to the same thing?)


Aliases vs Optimizations

Is it safe for this function to return the value 1?

What if p and q refer to the same int?

Conservative/safe: since it's possible, the compiler must assume it's always true!

C provides "restrict" keyword - where user asserts there is no aliasing


void f(int *p, int *q) { *p = 1; *q = 2;

return *p;

}

Types and Aliases (1)

In Java, ML, MiniJava, and others, if two variables have incompatible types they cannot be names for the same location

Also helps that programmer cannot create arbitrary pointers to storage in these languages


Types and Aliases (2)

Strategy: Divide memory locations into alias classes based on type information (every type, array, record field is a class)

Implication: need to propagate type information from the semantics pass to optimizer

Not normally true of a minimally typed IR

Items in different alias classes cannot refer to each other


Aliases and Flow Analysis

Idea: Base alias classes on points where a value is created

Every new/malloc and each local or global variable whose address is taken is an alias class

Pointers can refer to values in multiple alias classes (so each memory reference is to a set of alias classes)

Use to calculate “may alias” information (eg: p “may alias” q at program point s)


Using “may-alias” information

Treat each alias class as a “variable” in dataflow analysis problems

Example: framework for available expressions Given statement s: M[a]:=b,

gen[s] = { }kill[s] = { M[x] | a may alias x at s }


May-Alias Analysis

Without alias analysis, #2 kills M[t] since x and t might be related

If analysis determines that “x may-alias t” is false, M[t] is still available at #3; can eliminate the common sub-expression and use copy propagation

1: u = M[t]2: M[x] = r3: w = M[t]4: b = u+w



Dataflow analysis is core of classical optimizations

Still to explore: Discovering and optimizing loops SSA – Static Single Assignment form

Next

Spring 2014Jim Hogg - UW - CSE - P501R-1 CSE P501 – Compiler Construction Available Expressions...

Documents

Transcript of Spring 2014Jim Hogg - UW - CSE - P501R-1 CSE P501 – Compiler Construction Available Expressions...