Dataflow Analysis. A sample program int fib10(void) { int n = 10; int older = 0; int old = 1; Simple Constant Propagation
|
|
- Melissa Nicholson
- 5 years ago
- Views:
Transcription
1 -74 Lecture 2 Dataflow Analysis Basic Blocks Related Optimizations SSA Copyright Seth Copen Goldstein Dataflow Analysis Last time we looked at code transformations Constant propagation Copy propagation Common sub-expression elimination Today, dataflow analysis: How to determine if it is legal to perform such an optimization (Not doing analysis to determine if it is beneficial) Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein A sample program int fib0(void) { int n = 0; int older = 0; int old = ; int What result are = those 0; numbers? int i; : n <- 0 2: older <- 0 : old <- 4: result <- 0 : if n <= goto 4 6: i <- 2 7: if i > n goto if (n <= ) return n; for (i = 2; i<n; i++) { result = old + older; older = old; old = result; return result; : return result 4: return n 8: result <- old + older 9: older <- old 0: old <- result : i <- i + 2: JUMP 7 Lecture 2-74 Seth Copen Goldstein Simple Constant Propagation : n <- 0 2: older <- 0 : old < 4: result <- 0 Can we do SCP? How do we recognize it? : old <- : if n <= goto 4 What aren t we doing? 6: i <- 2 7: if i > n goto Metanote: keep opts simple! Use combined power 0: old <- result 8: result <- old + older 9: older <- old : i <- i + 2: JUMP 7 : return result 4: return n Lecture 2-74 Seth Copen Goldstein
2 Reaching Definitions A definition iti of variable v at program point d reaches program point u if there exists a path of control flow edges from d to u that does not contain a definition of v. : n < : older <- 0 : old < : result <- 0 : if n <= goto 4 6: i < : if i > n goto 4 8: result <- old + older 0 9: older <- old 0: old <- result : i <- i : JUMP 7 : return result 4: return n Lecture 2-74 Seth Copen Goldstein Reaching Definitions (ex) reaches, 7, and 4 2 reaches 8 Older in 8 is reached by 2 9 Tells us which definitions reach a particular use (ud-info) : n <- 0 2: older <- 0 : old <- 4: result <- 0 : if n <= goto 4 6: i <- 2 7: if i > n goto 8: result <- old + older 9: older <- old 0: old <- result : i <- i + 2: JUMP 7 : return result 4: return n Lecture 2-74 Seth Copen Goldstein Reaching Definitions (ex) reaches, 7, and 4 2 reaches 4, Really? 8 Meta-notes: Older in 8 is reached by (almost) always conservative only 2 know what we know Keep 9it simple: What opt(s), if run before this would help Tells What us about: which definitions : x <- 0 reach a 2: if (false) x<- particular use (ud-info) : x Does reach? What opt changes this? : n <- 0 2: older <- 0 : old <- 4: result <- 0 : if n <= goto 4 6: i <- 2 7: if i > n goto 8: result <- old + older 9: older <- old 0: old <- result : i <- i + 2: JUMP 7 : return result 4: return n Lecture 2-74 Seth Copen Goldstein Calculating Reaching Definitions A definition iti of variable v at program point d reaches program point u if there exists a path of control flow edges from d to u that does not contain a definition of v. Build up RD stmt by stmt Stmt s, d: v <- x op y, generates d Stmt s, d: v <- x op y, kills all other defs(v) Or, Gen[s] = { d Kill[s] = defs(v) { d Lecture 2-74 Seth Copen Goldstein
3 Gen and kill for each stmt Gen kill : n <- 0 2: older < : old <- 0 4: result < : if n <= goto 4 6: i < : if i > n goto 8: result <- old + older 8 4 9: older <- old 9 2 0:old <- result 0 : i <- i + 6 2: JUMP 7 : return result 4: return n How can we determine the defs that reach a node? We can use: control flow information gen and kill info Lecture 2-74 Seth Copen Goldstein In[: Out[: Computing in[ and out[ the set of defs that reach the beginning ng of node n the set of defs that reach the end of node n in[ = out[ [ p ] out[ = p pred[ gen [ n ] ( in [ n ] kill [ n ]) Initialize in[=out[={ for all n Solve iteratively Lecture 2-74 Seth Copen Goldstein What is pred[? Pred[ are all nodes that can reach n in the control flow graph. E.g., pred[7] = { 6, 2 : n < : older <- 0 : old < : result <- 0 : if n <= goto 4 6: i < : if i > n goto 4 8: result <- old + older 0 9: older <- old 0: old <- result : i <- i : JUMP 7 : return result 4: return n Lecture 2-74 Seth Copen Goldstein What order to eval nodes? Does it matter? Lets do:,2,,4,,4,6,7,,8,9,0,, : n < : older <- 0 : old < : result <- 0 : if n <= goto 4 6: i < : if i > n goto 4 8: result <- old + older 0 9: older <- old 0: old <- result : i <- i : JUMP 7 : return result 4: return n Lecture 2-74 Seth Copen Goldstein
4 Example: Order: ,2,,4,,4,6,7,,8,9,0,,2 in[ out[ p] = out[ = gen[ ( in[ kill[ ) p pred [ n ] Gen kill in out : n <- 0 2: older < ,2 : old <- 0,2-4: result < : if n <= goto 4 6: i < : if i > n goto 8: result <- old + older 8 4 9: older <- old 9 2 0: old <- result 0 : i <- i + 6 2: JUMP 7 : return result 4: return n Example (pass ) Order: ,2,,4,,4,6,7,,8,9,0,,2 in[ out[ p] = out[ = gen[ ( in[ kill[ ) p pred [ n ] Gen kill in out : n <- 0 2: older < ,2 : old <- 0,2,2, 4: result < : if n <= goto : i < ,6 7: if i > n goto -4,6-4,6 8: result <- old + older 8 4-4,6 -,6,8 9: older <- old 9 2 -,6,8,,6,8,9 0: old <- result 0,,6,8,9,6,8-0 : i <- i + 6,6,8-0,8-2: JUMP 7,8-,8- : return result -4,6-4,6 4: return n -4-4 Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein Example (pass 2) Order: ,2,,4,,4,6,7,,8,9,0,,2 in[ out[ p] = out[ = gen[ ( in[ kill[ ) p pred [ n ] Gen kill in out : n <- 0 2: older < ,2 : old <- 0,2,2, 4: result < : if n <= goto : i < ,6 7: if i > n goto -4,6,8- -4,6,8-8: result <- old + older 8 4-4,6,8- -,6,8-9: older <- old 9 2 -,6,8-,,6,8-0: old <- result 0,,6,8-,6,8- : i <- i + 6,6,8-,8-2: JUMP 7,8-,8- : return result -4,6-4,6 4: return n -4-4 Lecture 2-74 Seth Copen Goldstein An Improvement: Basic Blocks No need to compute this one stmt at a time For straight line code: In[s; s2] = in[s] Out[s; s2] = out[s2] Can we combine the gen and kill sets into one set per BB? Gen kill Gen[BB]={24 Gen[BB]={2,,4, Kill[BB]={,8, Gen[s;s2]= Kill[s;s2]= : i <- 8,4 2: j <- 2 2 : k <- + i 4: i <- j 4,8 : m <- i + k Lecture 2-74 Seth Copen Goldstein
5 BB sets BB sets Gen kill : n <- 0 2: older < : old <- 0 4: result < : if n <= goto 4,2,,4 8,9,0 6: i < : if i > n goto 8: result <- old + older 8 4 9: older <- old 9 2 0: old <- result 0 : i <- i + 6 2: JUMP ,6 : return result 4: return n 2 4 Gen={,2,,4 Kill={890 {8,9,0 Gen={6 Kill={ 6 Gen={8,9,0, Kill={2,,4,6 In out,2,,4 Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein BB sets Forward Dataflow 2 Gen={8,9,0, Kill={2,,4,6 4 6 Gen={,2,,4 Kill={890 {8,9,0 Gen={6 Kill={ In out,2,,4,2,,4,,,2,,4,6,,, -4,6, ,6, ,6, ,8- Reaching definitions is a forward dataflow problem: It propgates information from preds of a node to the node Defined by: Basic attributes: (gen and kill) Transfer function: out[b]=f bb (in[b]) Meet operator: in[b]=m(out[p]) for all p pred(b) Set of values (a lattice, in this case powerset of program points) ) Initial values for each node b Solve for fixed point solution Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein
6 How to implement? Values? Gen? Kill? F bb? Order to visit nodes? When are we done? In fact, do we know we terminate? Implementing RD Values: bits in a bit vector Gen: in each position generated, otherwise 0 Kill: 0 in each position killed, otherwise F bb : out[b] = (in[b] gen[b]) & kill[b] Init in[b]=out[b]=0 When are we done? What order to visit it nodes? Does it matter? Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein RD Worklist algorithm Initialize: in[b] = out[b] = Initialize: in[entry] = Work queue, W = all Blocks in topological order while ( W!= 0) { remove b from W old = out[b] in[b] = {over all pred(p) b out[p] out[b] = gen[b] (in[b] - kill[b]) if (old!= out[b]) W = W succ(b) Lecture 2-74 Seth Copen Goldstein Storing Rd information Use-def chains: for each use of var x in s, a list of definitions of x that reach s : n <- 0 2: older <- 0,2 : old <-,2,2, 4: result < : if n <= goto : i < ,6 7: if i > n goto -4,6,8- -4,6,8-8: result <- old + older -4,6,8- -,6,8-9: older <- old -,6,8-,,6,8-0:old <- result,,6,8-,6,8- : i <- i +,6,8-,8-2: JUMP 7,8-,8- : return result -4,6-4,6 4: return n -4-4 Lecture 2-74 Seth Copen Goldstein
7 Def-use chains are valuable too Def-use chain: for each definition of var x, a list of all uses of that definition Computed from liveness analysis, a backward dataflow problem Def-use and use-def are different z > x <- z > y x <- 2 y <- x + z <- x + Lecture 2-74 Seth Copen Goldstein Using RD for Simple Const. Prop. : n <- 0 2: older <- 0,2 : old <-,2,2, 4: result < : if n <= goto : i < ,6 7: if i > n goto -4,6,8- -4,6,8-8: result <- old + older -4,6,8- -,6,8-9: older <- old -,6,8-,,6,8-0:old <- result,,6,8-,6,8- : i <- i +,6,8-,8-2: JUMP 7,8-,8- : return result -4,6-4,6 4: return n -4-4 Lecture 2-74 Seth Copen Goldstein Better Constant Propagation Better Constant Propagation What about: x <- if (y > z) a <- x x <- What about: x <- Lattice if (y > z) a <- x x <- -inf inf Meet: a <- a <- a c <- c c <- c d ( if c d) Init all vars to: bot or top? Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein
8 Loop Invariant Code Motion Loop Invariant Code Motion When can expression be moved out of a loop? x <- y + z a <-.. x.. When can expression be moved out of a loop? When all reaching definitions of operands are outside of loop, expression is loop invariant Use ud-chains to detect Can du-chains be helpful? x <- y + z a <-.. x.. Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein Liveness (def-use chains) A variable x is live-out of a stmt s if x can be used along some path starting a s, otherwise x is dead. Why is this important? How can we frame this as a dataflow problem? Lecture 2-74 Seth Copen Goldstein Liveness as a dataflow problem This is a backwards analysis A variable is live out if used by a successor Gen: For a use: indicate it is live coming into s Kill: Defining a variable v in s makes it dead before s (unless s uses v to define v) Lattice is just live (top) and dead (bottom) Values are variables In[ = variables live before n = out[ kill[ gen[ Out[ = variables live after n = In[ s] s succ( n) Lecture 2-74 Seth Copen Goldstein
9 Dead Code Elimination Code is dead if it has no effect on the outcome of the program. When is code dead? Dead Code Elimination Code is dead if it has no effect on the outcome of the program. When is code dead? When the definition is dead, and When the instruction has no side effects So: run liveness Construct def-use chains Any instruction which has no users and has no side effects can be eliminated Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein When can we do CSE? Available Expressions? a <- 4 + i X+Y is available at statement S if x+y is computed along every path from the start to S AND neither x nor y is modified after the last evaluation of x+y b <- 4 + i a <- b+c b <- a-d c <- b+c d <- a-d Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein
10 Computing Available Expressions Forward or backward? Values? Lattice? gen[b] = kill[b] = in[b] = out[b] = initialization? iti Computing Available Expressions Forward Values: all expressions Lattice: available, not-avail gen[b] = if b evals expr e and doesn t define variables used in e kill[b] = if b assigns to x, then all exprs using x are killed. out[b] = in[b] kill[b] gen[b] in[b] = what to do at a join point? initialization? Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein Computing Available Expressions Forward Values: all expressions Lattice: available, not-avail gen[b] = if b evals expr e and doesn t define variables used in e kill[b] = if b assigns to x, exprs(x) are killed out[b] = in[b] kill[b] gen[b] in[b] = An expr is avail only if avail on ALL edges, so: in[b] = over all p pred(b), out[p] Initialization All nodes, but entry are set to ALL avail Entry is set to NONE avail Lecture 2-74 Seth Copen Goldstein Constructing Gen & Kill Stmt Gen Kill t <- x op y {x op y-kill[s] {exprs containing t t <- M[a] {M[a]-kill[s] M[a] <- b f(a, ) {M[x] for all x t <- f(a, ) Lecture 2-74 Seth Copen Goldstein
11 Constructing Gen & Kill Example Entry Stmt Gen Kill t <- x op y {x op y-kill[s] {exprs containing t t <- M[a] {M[a]-kill[s] {exprs containing t M[a] <- b { {for all x, M[x] f(a, ) { {for all x, M[x] t <- f(a, ) { {exprs containing t for all x, M[x] g[i] <- a*c c<-a+b d<-a*c e<-d*d i <- f[i] <- a+b c <- c*2 br c>d i <- i+ br i>0 g[i] <- d*d Exit Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein g[i] <- a*c Example Entry c<-a+b d <- a*c e<-d*d i <- f[i] <- a+b c <- c*2 br c>d Gen={a*c Kill={M[x] i <- i+ br i>0 Exit g[i] <- d*d Gen={a+b,a*c,d*d Kill={c>d,c*2,i>0,i+ Gen={a+b,c>d Kill={c*2,M[x],a*c Gen={i>0 Kill={i+ Gen={d*d Kill={M[x] Lecture 2-74 Seth Copen Goldstein Example W={ { In={ out={ Entry in={ c<-a+b 2 d<-a*c e<-d*d out={a+b, a*c, d*d, c>d, c*2, i>0, i+ i <- in={ f[i] <- a+b c <- c*2 out={a+b,a*c,d*d,c>d,c*2,i>0,i+ br c>d Gen={a+b,a*c,d*d Kill={c>d,c*2,i>0,i+ Gen={a+b,c>d Kill={c*2,M[x],a*c in={ in={ 4Gen={a*c g[i] <- a*c Gen={d*d Kill={M[x] g[i] <- d*d Kill={M[x] out={a+b,a*c,d*d,c>d,c*2,i>0,i+ in={ i <- i+ 6 Gen={i>0 br i>0 out={a+b,a*c,d*d,c>d,c*2,i>0,i+ a*c c>d c*2 i+ Kill={i+ in={ 7 Exit Lecture 2-74 Seth Copen Goldstein
12 W={ out={a+b, a*c, d*d Example In={ out={ in={ Entry c<-a+b 2 d <- a*c e<-d*d i <- in={ f[i] <- a+b c <- c*2 out={a+b,a*c,d*d,c>d,c*2,i>0,i+ br c>d Gen={a+b,a*c,d*d Kill={c>d,c*2,i>0,i+ Gen={a+b,c>d Kill={c*2,M[x],a*c in={ in={ 4Gen={a*c g[i] <- a*c Gen={d*d Kill={M[x] g[i] <- d*d Kill={M[x] out={a+b,a*c,d*d,c>d,c*2,i>0,i+ in={ i <- i+ 6 Gen={i>0 br i>0 out={a+b,a*c,d*d,c>d,c*2,i>0,i+ a*c c>d c*2 i+ Kill={i+ in={ 7 Exit Lecture 2-74 Seth Copen Goldstein W={6 out={a+b, a*c, d*d Example In={ out={ in={ Entry c<-a+b 2 d<-a*c e<-d*d i <- Gen={a+b,a*c,d*d Kill={c>d,c*2,i>0,i+ in={a+b, a*c, d*d f[i] <- a+b Gen={a+b,c>d c <- c*2 out={a+b, d*d, c>d Kill={c*2,M[x],a*c br c>d in={a+b, d*d, c>d in={a+b, d*d, c>d 4Gen={a*c g[i] <- a*c Gen={d*d Kill={M[x] g[i] <- d*d Kill={M[x] out={a+b, d*d, c>d, a*c out={a+b, d*d, c>d in={ i <- i+ 6 Gen={i>0 br i>0 out={a+b,a*c,d*d,c>d,c*2,i>0,i+ a*c c>d c*2 i+ Kill={i+ in={ 7 Exit Lecture 2-74 Seth Copen Goldstein W={,7 out={a+b, a*c, d*d Example In={ out={ in={ Entry c<-a+b 2 d <- a*c e<-d*d i <- Gen={a+b,a*c,d*d Kill={c>d,c*2,i>0,i+ in={a+b, a*c, d*d f[i] <- a+b Gen={a+b,c>d c <- c*2 out={a+b, d*d, c>d Kill={c*2,M[x],a*c br c>d in={a+b, d*d, c>d in={a+b, d*d, c>d 4Gen={a*c g[i] <- a*c Gen={d*d Kill={M[x] g[i] <- d*d Kill={M[x] out={a+b, d*d, c>d, a*c out={a+b, d*d, c>d in={a+b, d*d, c>d i <- i+ 6 Gen={i>0 br i>0 out={a+b, d*d, c>d, i>0 Kill={i+ in={ 7 Exit Lecture 2-74 Seth Copen Goldstein W={ out={a+b, a*c, d*d Example In={ out={ in={ Entry c<-a+b 2 d<-a*c e<-d*d i <- Gen={a+b,a*c,d*d Kill={c>d,c*2,i>0,i+ in={a+b, d*d f[i] <- a+b Gen={a+b,c>d c <- c*2 out={a+b, d*d, c>d Kill={c*2,M[x],a*c br c>d in={a+b, d*d, c>d in={a+b, d*d, c>d 4Gen={a*c g[i] <- a*c Gen={d*d Kill={M[x] g[i] <- d*d Kill={M[x] out={a+b, d*d, c>d, a*c out={a+b, d*d, c>d in={a+b, d*d, c>d i <- i+ 6 Gen={i>0 br i>0 out={a+b, d*d, c>d, i>0 Kill={i+ in={ 7 Exit Lecture 2-74 Seth Copen Goldstein
13 CSE Calculate Available expressions For every stmt in program If expression, x op y, is available { Compute reaching expressions for x op y at this stmt foreach stmt in RE of the form t <- x op y rewrite at: t <- x op y t <- t replace x op y in stmt with t Lecture 2-74 Seth Copen Goldstein W={ out={a+b, a*c, d*d Example In={ out={ in={ Entry c<-a+b 2 d<-a*c e<-d*d i <- Gen={a+b,a*c,d*d Kill={c>d,c*2,i>0,i+ in={a+b, d*d f[i] <- a+b Gen={a+b,c>d c <- c*2 out={a+b, d*d, c>d Kill={c*2,M[x],a*c br c>d in={a+b, d*d, c>d in={a+b, d*d, c>d 4Gen={a*c g[i] <- a*c Gen={d*d Kill={M[x] g[i] <- d*d Kill={M[x] out={a+b, d*d, c>d, a*c out={a+b, d*d, c>d in={a+b, d*d, c>d i <- i+ 6 Gen={i>0 br i>0 out={a+b, d*d, c>d, i>0 Kill={i+ in={ 7 Exit Lecture 2-74 Seth Copen Goldstein Calculating RE Could be dataflow problem, but not needed enough, so To find RE for x op y at stmt S traverse cfg backward from S until reach t <- x + y (& put into RE) reach definition of x or y Example Entry c<-a+b 2 d<-a*c e<-d*d i <- f[i] <- t ;a+b c <- c*2 br c>d t <- a+b c <- t t2 <- d*d e <- t2 g[i] <- a*c 4 g[i] <- t2 ; d*d i <- i+ 6 br i>0 Exit 7 Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein
14 Dataflow Summary Dataflow Framework Forward Backward Union Reaching defs Live variables intersection Available exprs Lattice Universe of values Meet operator Basic attributes (e.g., gen, kill) Traversal order Transfer function Later in course we look at bidirectional dataflow Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein Def-Use chains are expensive foo(int i, int j) { switch (i) { case 0: x=;break; case : x=; break; case 2: x=6; break; case : x=7; break; default: x = ; switch (j) { case 0: y=x+7; break; case : y=x+4; break; case 2: y=x-2; break; case : y=x+; break; default: y=x+9; Lecture 2-74 Seth Copen Goldstein Def-Use chains are expensive foo(int i, int j) { switch (i) { case 0: x=; case : x=; case 2: x=6; case : x=7; default: x = ; switch (j) { case 0: y=x+7; case : y=x+4; case 2: y=x-2; case : y=x+; default: y=x+9; In general, N defs M uses O(NM) space and time A solution is to limit each var to ONE def site Lecture 2-74 Seth Copen Goldstein
15 Def-Use chains are expensive foo(int i, int j) { switch (i) { case 0: x=; break; case : x=; break; case 2: x=6; case : x=7; default: x = ; x is one of the above x s switch (j) { A solution is to limit each case 0: y=x+7; var to ONE def site case : y=x+4; case 2: y=x-2; case : y=x+; default: y=x+9; Lecture 2-74 Seth Copen Goldstein Advantages of SSA Makes du-chains explicit Makes dataflow analysis easier Improves register allocation Automatically builds Webs Makes building interference graphs easier For most programs reduces space/time requirements Lecture 2-74 Seth Copen Goldstein SSA Static single assignment is an IR where every variable able is assigned a value at most once in the program text Easy for a basic block: assign to a fresh variable at each stmt. Each use uses the most recently defined var. (Similar to Value Numbering) a x + y b a + x a b + 2 c y + a c + a Straight-line SSA Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein
16 Straight-line SSA SSA a x + y b a + x a b + 2 c y + a c + a a x + y b a + x a 2 b + 2 c y + a c + a 2 Static single assignment is an IR where every variable able is assigned a value at most once in the program text Easy for a basic block: assign to a fresh variable at each stmt. Each use uses the most recently defined var. (Similar to Value Numbering) What about at joins in the CFG? Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein Merging at Joins c 2 c 2 if (i) { if (i) a x + y b a + x else { a b + 2 c y + a x + y b a + x a b + 2 c y + a 4 c? + a? a c + a SSA Static single assignment is an IR where every variable able is assigned a value at most once in the program text Easy for a basic block: assign to a fresh variable at each stmt. Each use uses the most recently defined var. (Similar to Value Numbering) What about at joins in the CFG? Use a notional fiction: A Φ function Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein
17 Merging at Joins a x + y b a + x c 2 if (i) a 2 b + 2 c 2 y + a Φ(a(,a 2 ) c Φ(c,c 2 ) b 2 Φ(b,?) The Φ function Φ merges multiple definitions along multiple control paths into a single definition. At a BB with p predecessors, there are p arguments to the Φ function. x new Φ(x, x, x,, x p ) How do we choose which x i to use? We don t really care! If we care, use moves on each incoming edge a 4 c + a Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein Implementing Φ c 2 if (i) a x + a 2 b + 2 y b a + x c 2 y + a a a a 2 c c c 2 c a Φ(a,a 2 ) c Φ(c,c 2 ) a 4 c + a Trivial SSA Each assignment generates a fresh variable. At each join point insert Φ functions for all live variables. x x y x y 2 y x y 2 2 Way too many Φ functions inserted. z y + x x 2 Φ(x,x ) y Φ(y,y 2 ) z y + x 2 Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein
18 Minimal SSA Another Example Each assignment generates a fresh variable. At each join point insert Φ functions for all variables with multiple outstanding defs. a 0 x y x y 2 x y x y 2 2 b a + c c + b a b * 2 a < N z y + x y Φ(y,y 2 ) z y + x return c Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein Another Example a 0 a 0 Notice use of c a Φ(a,a 2 ) b a + c Φ(c,c 2 ) c c + b b 2 a + a b * 2 c 2 c + b 2 a < N a 2 b 2 * 2 < N return c return c 2 Lecture 2-74 Seth Copen Goldstein a 2 Lets optimize the following: i=; j=; k=0; while (k<00) { if (j<20) { j=i; k++; else { j=k; k+=2; return j; i j k 0 2 k < 00? j < 20? 4 return j j i 6 j k k k + k k + 2 Lecture 2-74 Seth Copen Goldstein
19 i j k 0 First, turn into SSA 4 i j k 0 2 k < 00? 2 k < 00? j < 20? j i k k + return j 6 j k k k + 2 j < 20? j i k k + 4 return j 6 j k k k + 2 i j k 0 Properties of SSA Only assignment per variable definitions dominate j 2 Φ(j 4,j ) uses 2 k 2 Φ(k 4,k ) k 2 < 00? Can we use this to help with constant propagation? j i 6 j k 2 k k 2 + k k j 4 Φ(j,j ) k 4 Φ(k,k ) Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein Constant Propagation If v c, replace all uses of v with c If v Φ(c,c,c) replace all uses of v with c W <- list of all defs while!w.isempty { Stmt S <- W.removeOne if S has form v <- Φ(c,,c) replace S with V <- c if S has form v <- c then delete S foreach stmt U that uses v, replace v with c in U W.add(U) Lecture 2-74 Seth Copen Goldstein Other stuff we can do? Copy propagation delete x Φ(y) and replace all x with y delete x y and replace all x with y Constant Folding (Also, constant conditions too!) Unreachable Code Remember to delete all edges from unreachable block Lecture 2-74 Seth Copen Goldstein
20 Constant Propagation Constant Propagation i j k 0 i j k 0 j 2 Φ(j 4,j ) 2 k 2 Φ(k 4,k ) k 2 < 00? j 2 Φ(j 4,) 2 k 2 Φ(k 4,k ) k 2 < 00? j i k k j k 2 k k j 6 k k 2 + j k 2 k k j 4 Φ(j,j ) k 4 Φ(k,k ) Lecture 2-74 Seth Copen Goldstein j 4 Φ(j,j ) k 4 Φ(k,k ) Lecture 2-74 Seth Copen Goldstein Constant Propagation Constant Propagation i j k 0 i j k 0 j 2 Φ(j 4,) 2 k 2 Φ(k 4,k ) k 2 < 00? 2 j 2 k 2 Φ(j 4,) Φ(k 4,0) k 2 < 00? But, so what? You will have to wait til next time :) j k k j k 2 k k j k k j k 2 k k j 4 Φ(,j ) k 4 Φ(k,k ) Lecture 2-74 Seth Copen Goldstein j 4 Φ(,j ) k 4 Φ(k,k ) Lecture 2-74 Seth Copen Goldstein
21 Summary Dataflow framework Lattice, meet, direction, transfer function, initial values Du-chains chains, ud-chains CSE SSA One static definition per variable Φ-functions Conditional Constant Propagation i j k 0 j 2 Φ(j 4,) Does block 6 ever execute? Simple CP can t tell 2 k 2 Φ(k 4,0) CCP can tell: k 2 < 00? Assumes blocks don t execute until proven otherwise Assumes Values are constants until proven j 6 j k 2 otherwise k k 2 + k k j 4 Φ(,j ) k 4 Φ(k,k ) Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein Tracks: - Blocks (assume unexecuted until proven otherwise) - Variables (assume not executed, only with proof of assignments of a non-constant value do we assume not constant) Use a lattice for variables: TOP = we have evidence that variable can hold different values at different times integers = we have seen evidence that t the var has been assigned a constant with the value BOT = not executed Lecture 2-74 Seth Copen Goldstein Conditional Constant Propagation i j k 0 j 2 Φ(j 4,) 2 k 2 Φ(k 4,0) k 2 < 00? j 6 k k j k 2 k k j 4 Φ(,j ) k 4 Φ(k,k ) Lecture 2-74 Seth Copen Goldstein
22 Conditional Constant Propagation i j k 0 Conditional Constant Propagation i j k 0 j 2 Φ(j 4,) 2 k 2 Φ(k 4,0) k 2 < 00? j 6 k k 2 + j k 2 k k j 2 Φ(j 4,) 2 k 2 Φ(k 4,0) k 2 < 00? j 6 k k 2 + j k 2 k k j 4 Φ(,j ) k 4 Φ(k,k ) 7 j 4 Φ(,j ) k 4 Φ(k,k ) Lecture 2-74 Seth Copen Goldstein Lecture 2-74 Seth Copen Goldstein Conditional Constant Propagation i j k 0 Conditional Constant Propagation i j k 0 j 2 Φ(j 4,) 2 k 2 Φ(k 4,0) k 2 < 00? j 6 k k 2 + j k 2 k k j 2 Φ(j 4,) k 2 TOP 2 Φ(k 4,0) k 2 < 00? j 6 k k 2 + j k 2 k k j 4 Φ(,j ) k 4 Φ(k,k ) Lecture 2-74 Seth Copen Goldstein j 4 Φ(,j ) k 4 Φ(k,k ) Lecture 2-74 Seth Copen Goldstein
23 Conditional Constant Propagation i j k 0 i j k 0 CCP j 2 Φ(j 4,) k 2 TOP 2 Φ(k 4,0) k 2 < 00? j 6 k k j k 2 k k j 4 Φ(,j ) k 4 Φ(k,k ) Lecture 2-74 Seth Copen Goldstein j 2 Φ(j,j ) 2 k 2 Φ(k 4,k ) k < 00? j i 6 j k 2 k k 2 + k k j 4 Φ(j,j ) k 4 Φ(k,k ) k 2 Φ(k,0) k 2 < 00? k k 2 + return Lecture 2-74 Seth Copen Goldstein
Dataflow Analysis Lecture 2. Simple Constant Propagation. A sample program int fib10(void) {
-4 Lecture Dataflow Analysis Basic Blocks Related Optimizations Copyright Seth Copen Goldstein 00 Dataflow Analysis Last time we looked at code transformations Constant propagation Copy propagation Common
More informationCSC D70: Compiler Optimization Static Single Assignment (SSA)
CSC D70: Compiler Optimization Static Single Assignment (SSA) Prof. Gennady Pekhimenko University of Toronto Winter 08 The content of this lecture is adapted from the lectures of Todd Mowry and Phillip
More informationLecture 5 Introduction to Data Flow Analysis
Lecture 5 Introduction to Data Flow Analysis I. Structure of data flow analysis II. III. IV. Example 1: Reaching definition analysis Example 2: Liveness analysis Framework Phillip B. Gibbons 15-745: Intro
More informationCompiler Design. Data Flow Analysis. Hwansoo Han
Compiler Design Data Flow Analysis Hwansoo Han Control Flow Graph What is CFG? Represents program structure for internal use of compilers Used in various program analyses Generated from AST or a sequential
More informationTopic-I-C Dataflow Analysis
Topic-I-C Dataflow Analysis 2012/3/2 \course\cpeg421-08s\topic4-a.ppt 1 Global Dataflow Analysis Motivation We need to know variable def and use information between basic blocks for: constant folding dead-code
More informationLecture 4 Introduc-on to Data Flow Analysis
Lecture 4 Introduc-on to Data Flow Analysis I. Structure of data flow analysis II. Example 1: Reaching defini?on analysis III. Example 2: Liveness analysis IV. Generaliza?on 15-745: Intro to Data Flow
More information(b). Identify all basic blocks in your three address code. B1: 1; B2: 2; B3: 3,4,5,6; B4: 7,8,9; B5: 10; B6: 11; B7: 12,13,14; B8: 15;
(a). Translate the program into three address code as defined in Section 6.2, dragon book. (1) i := 2 (2) if i > n goto (7) (3) a[i] := TRUE (4) t2 := i+1 (5) i := t2 (6) goto (2) (7) count := 0 (8) s
More informationData flow analysis. DataFlow analysis
Data flow analysis DataFlow analysis compile time reasoning about the runtime flow of values in the program represent facts about runtime behavior represent effect of executing each basic block propagate
More informationGeneralizing Data-flow Analysis
Generalizing Data-flow Analysis Announcements PA1 grades have been posted Today Other types of data-flow analysis Reaching definitions, available expressions, reaching constants Abstracting data-flow analysis
More informationCMSC 631 Program Analysis and Understanding. Spring Data Flow Analysis
CMSC 631 Program Analysis and Understanding Spring 2013 Data Flow Analysis Data Flow Analysis A framework for proving facts about programs Reasons about lots of little facts Little or no interaction between
More information3/11/18. Final Code Generation and Code Optimization
Final Code Generation and Code Optimization 1 2 3 for ( i=0; i < N; i++) { base = &a[0]; crt = *(base + i); } original code base = &a[0]; for ( i=0; i < N; i++) { crt = *(base + i); } optimized code e1
More informationData-Flow Analysis. Compiler Design CSE 504. Preliminaries
Data-Flow Analysis Compiler Design CSE 504 1 Preliminaries 2 Live Variables 3 Data Flow Equations 4 Other Analyses Last modifled: Thu May 02 2013 at 09:01:11 EDT Version: 1.3 15:28:44 2015/01/25 Compiled
More informationData Flow Analysis (I)
Compiler Design Data Flow Analysis (I) Hwansoo Han Control Flow Graph What is CFG? Represents program structure for internal use of compilers Used in various program analyses Generated from AST or a sequential
More informationAdventures in Dataflow Analysis
Adventures in Dataflow Analysis CSE 401 Section 9-ish Jack Eggleston, Aaron Johnston, & Nate Yazdani Announcements - Code Generation due Announcements - Code Generation due - Compiler Additions due next
More informationCompiler Design Spring 2017
Compiler Design Spring 2017 8.6 Live variables Dr. Zoltán Majó Compiler Group Java HotSpot Virtual Machine Oracle Corporation Last lecture Definition: A variable V is live at point P if there is a path
More informationDataflow analysis. Theory and Applications. cs6463 1
Dataflow analysis Theory and Applications cs6463 1 Control-flow graph Graphical representation of runtime control-flow paths Nodes of graph: basic blocks (straight-line computations) Edges of graph: flows
More informationCompiler Design Spring 2017
Compiler Design Spring 2017 8.5 Reaching definitions Dr. Zoltán Majó Compiler Group Java HotSpot Virtual Machine Oracle Corporation Admin issues Brief reminder: Code review takes place today @ 15:15 You
More informationWhat is SSA? each assignment to a variable is given a unique name all of the uses reached by that assignment are renamed
Another Form of Data-Flow Analysis Propagation of values for a variable reference, where is the value produced? for a variable definition, where is the value consumed? Possible answers reaching definitions,
More informationData Flow Analysis. Lecture 6 ECS 240. ECS 240 Data Flow Analysis 1
Data Flow Analysis Lecture 6 ECS 240 ECS 240 Data Flow Analysis 1 The Plan Introduce a few example analyses Generalize to see the underlying theory Discuss some more advanced issues ECS 240 Data Flow Analysis
More informationCSC D70: Compiler Optimization Dataflow-2 and Loops
CSC D70: Compiler Optimization Dataflow-2 and Loops Prof. Gennady Pekhimenko University of Toronto Winter 2018 The content of this lecture is adapted from the lectures of Todd Mowry and Phillip Gibbons
More informationStatic Program Analysis
Static Program Analysis Xiangyu Zhang The slides are compiled from Alex Aiken s Michael D. Ernst s Sorin Lerner s A Scary Outline Type-based analysis Data-flow analysis Abstract interpretation Theorem
More informationLecture 11: Data Flow Analysis III
CS 515 Programming Language and Compilers I Lecture 11: Data Flow Analysis III (The lectures are based on the slides copyrighted by Keith Cooper and Linda Torczon from Rice University.) Zheng (Eddy) Zhang
More informationLecture 10: Data Flow Analysis II
CS 515 Programming Language and Compilers I Lecture 10: Data Flow Analysis II (The lectures are based on the slides copyrighted by Keith Cooper and Linda Torczon from Rice University.) Zheng (Eddy) Zhang
More informationScalar Optimisation Part 2
Scalar Optimisation Part 2 Michael O Boyle January 2014 1 Course Structure L1 Introduction and Recap 4-5 lectures on classical optimisation 2 lectures on scalar optimisation Last lecture on redundant expressions
More information: Compiler Design. 9.5 Live variables 9.6 Available expressions. Thomas R. Gross. Computer Science Department ETH Zurich, Switzerland
252-210: Compiler Design 9.5 Live variables 9.6 Available expressions Thomas R. Gross Computer Science Department ETH Zurich, Switzerland Outline Warp up reaching definifons Live variables Available expressions
More informationWe define a dataflow framework. A dataflow framework consists of:
So far been talking about various dataflow problems (e.g. reaching definitions, live variable analysis) in very informal terms. Now we will discuss a more fundamental approach to handle many of the dataflow
More informationDataflow Analysis. Chapter 9, Section 9.2, 9.3, 9.4
Dataflow Analysis Chapter 9, Section 9.2, 9.3, 9.4 2 Dataflow Analysis Dataflow analysis is a sub area of static program analysis Used in the compiler back end for optimizations of three address code and
More informationIntroduction to data-flow analysis. Data-flow analysis. Control-flow graphs. Data-flow analysis. Example: liveness. Requirements
Data-flow analysis Michel Schinz based on material by Erik Stenman and Michael Schwartzbach Introduction to data-flow analysis Data-flow analysis Example: liveness Data-flow analysis is a global analysis
More informationMonotone Data Flow Analysis Framework
Monotone Data Flow Analysis Framework Definition. A relation R on a set S is (a) reflexive iff ( x S)[xRx], (b) antisymmetric iff [xry yrx x=y] (c) transitive iff ( x,y,z S) [xry yrz xrz] Definition. A
More informationComputing Static Single Assignment (SSA) Form
Computing Static Single Assignment (SSA) Form Overview What is SSA? Advantages of SSA over use-def chains Flavors of SSA Dominance frontiers revisited Inserting φ-nodes Renaming the variables Translating
More informationDataflow Analysis. Dragon book, Chapter 9, Section 9.2, 9.3, 9.4
Dataflow Analysis Dragon book, Chapter 9, Section 9.2, 9.3, 9.4 2 Dataflow Analysis Dataflow analysis is a sub-area of static program analysis Used in the compiler back end for optimizations of three-address
More informationMIT Martin Rinard Laboratory for Computer Science Massachusetts Institute of Technology
MIT 6.035 Foundations of Dataflow Analysis Martin Rinard Laboratory for Computer Science Massachusetts Institute of Technology Dataflow Analysis Compile-Time Reasoning About Run-Time Values of Variables
More informationStatic Analysis of Programs: A Heap-Centric View
Static Analysis of Programs: A Heap-Centric View (www.cse.iitb.ac.in/ uday) Department of Computer Science and Engineering, Indian Institute of Technology, Bombay 5 April 2008 Part 1 Introduction ETAPS
More informationLecture Overview SSA Maximal SSA Semipruned SSA o Placing -functions o Renaming Translation out of SSA Using SSA: Sparse Simple Constant Propagation
1 Lecture Overview SSA Maximal SSA Semipruned SSA o Placing -functions o Renaming Translation out of SSA Using SSA: Sparse Simple Constant Propagation [Chapter 9] 2 SSA Revisited It is desirable to use
More informationDepartment of Computer Science and Engineering, IIT Kanpur, INDIA. Code Optimization. Sanjeev K Aggarwal Code Optimization 1 of I
Code Optimization Sanjeev K Aggarwal Code Optimization 1 of 23 2007-08-I Code Optimization int a,b,c,d ldw a,r1 add r1,r2,r3 c = a+b ldw b,r2 add r3,1,r4 d = c+1 add r1,r2,r3 stw r3,c ldw c,r3 add r3,1,r4
More informationMIT Loop Optimizations. Martin Rinard
MIT 6.035 Loop Optimizations Martin Rinard Loop Optimizations Important because lots of computation occurs in loops We will study two optimizations Loop-invariant code motion Induction variable elimination
More informationTopics on Compilers
Assignment 2 4541.775 Topics on Compilers Sample Solution 1. Test for dependences on S. Write down the subscripts. Which positions are separable, which are coupled? Which dependence test would you apply
More informationScalar Optimisation Part 1
calar Optimisation Part 1 Michael O Boyle January, 2014 1 Course tructure L1 Introduction and Recap 4/5 lectures on classical optimisation 2 lectures on scalar optimisation Today example optimisations
More informationReading: Chapter 9.3. Carnegie Mellon
I II Lecture 3 Foundation of Data Flow Analysis Semi-lattice (set of values, meet operator) Transfer functions III Correctness, precision and convergence IV Meaning of Data Flow Solution Reading: Chapter
More informationCOSE312: Compilers. Lecture 17 Intermediate Representation (2)
COSE312: Compilers Lecture 17 Intermediate Representation (2) Hakjoo Oh 2017 Spring Hakjoo Oh COSE312 2017 Spring, Lecture 17 May 31, 2017 1 / 19 Common Intermediate Representations Three-address code
More informationCS 553 Compiler Construction Fall 2006 Homework #2 Dominators, Loops, SSA, and Value Numbering
CS 553 Compiler Construction Fall 2006 Homework #2 Dominators, Loops, SSA, and Value Numbering Answers Write your answers on another sheet of paper. Homework assignments are to be completed individually.
More informationCSE P 501 Compilers. Value Numbering & Op;miza;ons Hal Perkins Winter UW CSE P 501 Winter 2016 S-1
CSE P 501 Compilers Value Numbering & Op;miza;ons Hal Perkins Winter 2016 UW CSE P 501 Winter 2016 S-1 Agenda Op;miza;on (Review) Goals Scope: local, superlocal, regional, global (intraprocedural), interprocedural
More informationThe Meet-Over-All-Paths Solution to Data-Flow Problems
The Meet-Over-All-Paths Solution to Data-Flow Problems Consider a monotone dataflow framework (L,,F). Assume that the functions f B F represent the effect of a basic block on the sets conatining data for
More informationDataflow Analysis - 2. Monotone Dataflow Frameworks
Dataflow Analysis - 2 Monotone dataflow frameworks Definition Convergence Safety Relation of MOP to MFP Constant propagation Categorization of dataflow problems DataflowAnalysis 2, Sp06 BGRyder 1 Monotone
More informationIterative Dataflow Analysis
Iterative Dataflow Analysis CS 352 9/24/07 Slides adapted from Nielson, Nielson, Hankin Principles of Program Analysis Key Ideas Need a mechanism to evaluate (statically) statements in a program Problem:
More informationConstruction of Static Single-Assignment Form
COMP 506 Rice University Spring 2018 Construction of Static Single-Assignment Form Part II source IR IR target code Front End Optimizer Back End code Copyright 2018, Keith D. Cooper & Linda Torczon, all
More informationOptimizing Finite Automata
Optimizing Finite Automata We can improve the DFA created by MakeDeterministic. Sometimes a DFA will have more states than necessary. For every DFA there is a unique smallest equivalent DFA (fewest states
More informationMechanics of Static Analysis
Escuela 03 III / 1 Mechanics of Static Analysis David Schmidt Kansas State University www.cis.ksu.edu/~schmidt Escuela 03 III / 2 Outline 1. Small-step semantics: trace generation 2. State generation and
More informationWorst-Case Execution Time Analysis. LS 12, TU Dortmund
Worst-Case Execution Time Analysis Prof. Dr. Jian-Jia Chen LS 12, TU Dortmund 02, 03 May 2016 Prof. Dr. Jian-Jia Chen (LS 12, TU Dortmund) 1 / 53 Most Essential Assumptions for Real-Time Systems Upper
More informationRegister machines L2 18
Register machines L2 18 Algorithms, informally L2 19 No precise definition of algorithm at the time Hilbert posed the Entscheidungsproblem, just examples. Common features of the examples: finite description
More informationDFA of non-distributive properties
DFA of non-distributive properties The general pattern of Dataflow Analysis GA (p)= i if p E { GA (q) q F } otherwise GA (p)= f p ( GA (p) ) where : E is the set of initial/final points of the control-flow
More informationReduced Ordered Binary Decision Diagrams
Reduced Ordered Binary Decision Diagrams Lecture #13 of Advanced Model Checking Joost-Pieter Katoen Lehrstuhl 2: Software Modeling & Verification E-mail: katoen@cs.rwth-aachen.de June 5, 2012 c JPK Switching
More informationSymbolic Model Checking with ROBDDs
Symbolic Model Checking with ROBDDs Lecture #13 of Advanced Model Checking Joost-Pieter Katoen Lehrstuhl 2: Software Modeling & Verification E-mail: katoen@cs.rwth-aachen.de December 14, 2016 c JPK Symbolic
More informationClass 5. Review; questions. Data-flow Analysis Review. Slicing overview Problem Set 2: due 9/3/09 Problem Set 3: due 9/8/09
Class 5 Review; questions Assign (see Schedule for links) Slicing overview Problem Set 2: due 9/3/09 Problem Set 3: due 9/8/09 1 Data-flow Analysis Review Start at slide 21 of Basic Analysis 3 1 Static
More informationSparse Analysis of Variable Path Predicates Based Upon SSA-Form
Sparse Analysis of Variable Path Predicates Based Upon SSA-Form Thomas S. Heinze and Wolfram Amme Institute of Computer Science, Friedrich Schiller University Jena, Germany {t.heinze,wolfram.amme}@uni-jena.de
More information: Advanced Compiler Design Compu=ng DF(X) 3.4 Algorithm for inser=on of φ func=ons 3.5 Algorithm for variable renaming
263-2810: Advanced Compiler Design 3.3.2 Compu=ng DF(X) 3.4 Algorithm for inser=on of φ func=ons 3.5 Algorithm for variable renaming Thomas R. Gross Computer Science Department ETH Zurich, Switzerland
More informationComputational Boolean Algebra. Pingqiang Zhou ShanghaiTech University
Computational Boolean Algebra Pingqiang Zhou ShanghaiTech University Announcements Written assignment #1 is out. Due: March 24 th, in class. Programming assignment #1 is out. Due: March 24 th, 11:59PM.
More information(a) Definition of TMs. First Problem of URMs
Sec. 4: Turing Machines First Problem of URMs (a) Definition of the Turing Machine. (b) URM computable functions are Turing computable. (c) Undecidability of the Turing Halting Problem That incrementing
More informationRegister Allocation. Maryam Siahbani CMPT 379 4/5/2016 1
Register Allocation Maryam Siahbani CMPT 379 4/5/2016 1 Register Allocation Intermediate code uses unlimited temporaries Simplifying code generation and optimization Complicates final translation to assembly
More informationProgram Analysis. Lecture 5. Rayna Dimitrova WS 2016/2017
Program Analysis Lecture 5 Rayna Dimitrova WS 2016/2017 2/21 Recap: Constant propagation analysis Goal: For each program point, determine whether a variale has a constant value whenever an execution reaches
More informationPath Testing and Test Coverage. Chapter 9
Path Testing and Test Coverage Chapter 9 Structural Testing Also known as glass/white/open box testing Structural testing is based on using specific knowledge of the program source text to define test
More informationPath Testing and Test Coverage. Chapter 9
Path Testing and Test Coverage Chapter 9 Structural Testing Also known as glass/white/open box testing Structural testing is based on using specific knowledge of the program source text to define test
More informationCS415 Compilers Syntax Analysis Top-down Parsing
CS415 Compilers Syntax Analysis Top-down Parsing These slides are based on slides copyrighted by Keith Cooper, Ken Kennedy & Linda Torczon at Rice University Announcements Midterm on Thursday, March 13
More informationGoal. Partially-ordered set. Game plan 2/2/2013. Solving fixpoint equations
Goal Solving fixpoint equations Many problems in programming languages can be formulated as the solution of a set of mutually recursive equations: D: set, f,g:dxd D x = f(x,y) y = g(x,y) Examples Parsing:
More informationAlgebra 1. Predicting Patterns & Examining Experiments. Unit 5: Changing on a Plane Section 4: Try Without Angles
Section 4 Examines triangles in the coordinate plane, we will mention slope, but not angles (we will visit angles in Unit 6). Students will need to know the definition of collinear, isosceles, and congruent...
More information6.001 Recitation 22: Streams
6.001 Recitation 22: Streams RI: Gerald Dalley, dalleyg@mit.edu, 4 May 2007 http://people.csail.mit.edu/dalleyg/6.001/sp2007/ The three chief virtues of a programmer are: Laziness, Impatience and Hubris
More informationCSE 331 Winter 2018 Reasoning About Code I
CSE 331 Winter 2018 Reasoning About Code I Notes by Krysta Yousoufian Original lectures by Hal Perkins Additional contributions from Michael Ernst, David Notkin, and Dan Grossman These notes cover most
More informationAST rewriting. Part I: Specifying Transformations. Imperative object programs. The need for path queries. fromentry, paths, toexit.
Part I: Specifying Transformations Oege de Moor Ganesh Sittampalam Programming Tools Group, Oxford focus AST rewriting To apply rule: rewrite(pat 0, pat 1 ) Match: focus = φ(pat 0 ) Replace: focus := φ(pat
More informationLesson 3-1: Solving Linear Systems by Graphing
For the past several weeks we ve been working with linear equations. We ve learned how to graph them and the three main forms they can take. Today we re going to begin considering what happens when we
More informationSoftware Verification
Software Verification Grégoire Sutre LaBRI, University of Bordeaux, CNRS, France Summer School on Verification Technology, Systems & Applications September 2008 Grégoire Sutre Software Verification VTSA
More informationThe Reachability-Bound Problem. Gulwani and Zuleger PLDI 10
The Reachability-Bound Problem Gulwani and Zuleger PLDI 10 CS252r Spring 2011 The Reachability-Bound problem Find a symbolic worst case bound on the number of times a program point is reached Intra-procedural:
More informationSpace-aware data flow analysis
Space-aware data flow analysis C. Bernardeschi, G. Lettieri, L. Martini, P. Masci Dip. di Ingegneria dell Informazione, Università di Pisa, Via Diotisalvi 2, 56126 Pisa, Italy {cinzia,g.lettieri,luca.martini,paolo.masci}@iet.unipi.it
More informationModel Checking & Program Analysis
Model Checking & Program Analysis Markus Müller-Olm Dortmund University Overview Introduction Model Checking Flow Analysis Some Links between MC and FA Conclusion Apology for not giving proper credit to
More informationEDA045F: Program Analysis LECTURE 10: TYPES 1. Christoph Reichenbach
EDA045F: Program Analysis LECTURE 10: TYPES 1 Christoph Reichenbach In the last lecture... Performance Counters Challenges in Dynamic Performance Analysis Taint Analysis Binary Instrumentation 2 / 44 Types
More informationWorst-Case Execution Time Analysis. LS 12, TU Dortmund
Worst-Case Execution Time Analysis Prof. Dr. Jian-Jia Chen LS 12, TU Dortmund 09/10, Jan., 2018 Prof. Dr. Jian-Jia Chen (LS 12, TU Dortmund) 1 / 43 Most Essential Assumptions for Real-Time Systems Upper
More informationPart V. Matchings. Matching. 19 Augmenting Paths for Matchings. 18 Bipartite Matching via Flows
Matching Input: undirected graph G = (V, E). M E is a matching if each node appears in at most one Part V edge in M. Maximum Matching: find a matching of maximum cardinality Matchings Ernst Mayr, Harald
More informationCSE 431/531: Analysis of Algorithms. Dynamic Programming. Lecturer: Shi Li. Department of Computer Science and Engineering University at Buffalo
CSE 431/531: Analysis of Algorithms Dynamic Programming Lecturer: Shi Li Department of Computer Science and Engineering University at Buffalo Paradigms for Designing Algorithms Greedy algorithm Make a
More informationMaterial Covered on the Final
Material Covered on the Final On the final exam, you are responsible for: Anything covered in class, except for stories about my good friend Ken Kennedy All lecture material after the midterm ( below the
More information1300 Linear Algebra and Vector Geometry
1300 Linear Algebra and Vector Geometry R. Craigen Office: MH 523 Email: craigenr@umanitoba.ca May-June 2017 Introduction: linear equations Read 1.1 (in the text that is!) Go to course, class webpages.
More informationDO i 1 = L 1, U 1 DO i 2 = L 2, U 2... DO i n = L n, U n. S 1 A(f 1 (i 1,...,i, n ),...,f, m (i 1,...,i, n )) =...
15-745 Lecture 7 Data Dependence in Loops 2 Complex spaces Delta Test Merging vectors Copyright Seth Goldstein, 2008-9 Based on slides from Allen&Kennedy 1 The General Problem S 1 A(f 1 (i 1,,i n ),,f
More informationFirst Derivative Test
MA 2231 Lecture 22 - Concavity and Relative Extrema Wednesday, November 1, 2017 Objectives: Introduce the Second Derivative Test and its limitations. First Derivative Test When looking for relative extrema
More informationSaturday, April 23, Dependence Analysis
Dependence Analysis Motivating question Can the loops on the right be run in parallel? i.e., can different processors run different iterations in parallel? What needs to be true for a loop to be parallelizable?
More informationHigher-Order Equations: Extending First-Order Concepts
11 Higher-Order Equations: Extending First-Order Concepts Let us switch our attention from first-order differential equations to differential equations of order two or higher. Our main interest will be
More informationCSE 417. Chapter 4: Greedy Algorithms. Many Slides by Kevin Wayne. Copyright 2005 Pearson-Addison Wesley. All rights reserved.
CSE 417 Chapter 4: Greedy Algorithms Many Slides by Kevin Wayne. Copyright 2005 Pearson-Addison Wesley. All rights reserved. 1 Greed is good. Greed is right. Greed works. Greed clarifies, cuts through,
More informationFall 2011 Prof. Hyesoon Kim
Fall 2011 Prof. Hyesoon Kim Add: 2 cycles FE_stage add r1, r2, r3 FE L ID L EX L MEM L WB L add add sub r4, r1, r3 sub sub add add mul r5, r2, r3 mul sub sub add add mul sub sub add add mul sub sub add
More informationNotes for Comp 497 (454) Week 10
Notes for Comp 497 (454) Week 10 Today we look at the last two chapters in Part II. Cohen presents some results concerning the two categories of language we have seen so far: Regular languages (RL). Context-free
More informationIntra-procedural Data Flow Analysis Backwards analyses
Live variables Dead code elimination Very Busy Expressions Code hoisting Bitvector frameworks Monotone frameworks Intra-procedural Data Flow Analysis Backwards analyses Hanne Riis Nielson and Flemming
More informationProbabilistic Model Checking and [Program] Analysis (CO469)
Probabilistic Model Checking and [Program] Analysis (CO469) Program Analysis Herbert Wiklicky herbert@doc.ic.ac.uk Spring 208 / 64 Overview Topics we will cover in this part will include:. Language WHILE
More informationProgram verification
Program verification Data-flow analyses, numerical domains Laure Gonnord and David Monniaux University of Lyon / LIP September 29, 2015 1 / 75 Context Program Verification / Code generation: Variables
More informationModels of Computation, Recall Register Machines. A register machine (sometimes abbreviated to RM) is specified by:
Models of Computation, 2010 1 Definition Recall Register Machines A register machine (sometimes abbreviated M) is specified by: Slide 1 finitely many registers R 0, R 1,..., R n, each capable of storing
More informationCSE 200 Lecture Notes Turing machine vs. RAM machine vs. circuits
CSE 200 Lecture Notes Turing machine vs. RAM machine vs. circuits Chris Calabro January 13, 2016 1 RAM model There are many possible, roughly equivalent RAM models. Below we will define one in the fashion
More informationCSC 5170: Theory of Computational Complexity Lecture 4 The Chinese University of Hong Kong 1 February 2010
CSC 5170: Theory of Computational Complexity Lecture 4 The Chinese University of Hong Kong 1 February 2010 Computational complexity studies the amount of resources necessary to perform given computations.
More informationSection Summary. Relations and Functions Properties of Relations. Combining Relations
Chapter 9 Chapter Summary Relations and Their Properties n-ary Relations and Their Applications (not currently included in overheads) Representing Relations Closures of Relations (not currently included
More informationCS781 Lecture 3 January 27, 2011
CS781 Lecture 3 January 7, 011 Greedy Algorithms Topics: Interval Scheduling and Partitioning Dijkstra s Shortest Path Algorithm Minimum Spanning Trees Single-Link k-clustering Interval Scheduling Interval
More informationCausal Dataflow Analysis for Concurrent Programs
Causal Dataflow Analysis for Concurrent Programs Azadeh Farzan P. Madhusudan Department of Computer Science, University of Illinois at Urbana-Champaign. {afarzan,madhu}@cs.uiuc.edu Abstract. We define
More informationCS20a: Turing Machines (Oct 29, 2002)
CS20a: Turing Machines (Oct 29, 2002) So far: DFA = regular languages PDA = context-free languages Today: Computability 1 Church s thesis The computable functions are the same as the partial recursive
More informationTHEORY OF COMPILATION
Lecture 04 Syntax analysis: top-down and bottom-up parsing THEORY OF COMPILATION EranYahav 1 You are here Compiler txt Source Lexical Analysis Syntax Analysis Parsing Semantic Analysis Inter. Rep. (IR)
More informationCompilation and Program Analysis (#8) : Abstract Interpretation
Compilation and Program Analysis (#8) : Abstract Interpretation Laure Gonnord http://laure.gonnord.org/pro/teaching/capm.html Laure.Gonnord@ens-lyon.fr Master, ENS de Lyon Nov 7 Objective Compilation vs
More informationMath101, Sections 2 and 3, Spring 2008 Review Sheet for Exam #2:
Math101, Sections 2 and 3, Spring 2008 Review Sheet for Exam #2: 03 17 08 3 All about lines 3.1 The Rectangular Coordinate System Know how to plot points in the rectangular coordinate system. Know the
More informationSyntax Analysis, VII The Canonical LR(1) Table Construction. Comp 412
COMP 412 FALL 2018 Syntax Analysis, VII The Canonical LR(1) Table Construction Comp 412 source code IR IR target Front End Optimizer Back End code Copyright 2018, Keith D. Cooper & Linda Torczon, all rights
More information