Data-Flow Analysis: Proving Theorems and Reaching Definitions, Slides of Compilers

Download Data-Flow Analysis: Proving Theorems and Reaching Definitions and more Slides Compilers in PDF only on Docsity! Data-Flow Analysis Proving Little Theorems Data-Flow Equations Major Examples 1 Docsity.com An Obvious Theorem boolean x = true; while (x) { . . . // no change to x } • Doesn’t terminate. • Proof: only assignment to x is at top, so x is always true. 2 Docsity.com Example: Reaching Definitions 5 d1: x = true if x == true d2: a = 10 d2 d1 d1 d2 d1 Docsity.com Clincher • Since at x == true, d1 is the only definition of x that reaches, it must be that x is true at that point. • The conditional is not really a conditional and can be replaced by a branch. 6 Docsity.com Not Always That Easy int i = 2; int j = 3; while (i != j) { if (i < j) i += 2; else j += 2; } • We’ll develop techniques for this problem, but later … 7 Docsity.com Be Conservative! • (Code optimization only) • It’s OK to discover a subset of the opportunities to make some code-improving transformation. • It’s not OK to think you have an opportunity that you don’t really have. 10 Docsity.com Example: Be Conservative boolean x = true; while (x) { . . . *p = false; . . . } • Is it possible that p points to x? 11 Docsity.com As a Flow Graph 12 d1: x = true if x == true d2: *p = false d1 d2 Another def of x Docsity.com Data-Flow Equations --- (1) • A basic block can generate a definition. • A basic block can either 1. Kill a definition of x if it surely redefines x. 2. Transmit a definition if it may not redefine the same variable(s) as that definition. 15 Docsity.com Data-Flow Equations --- (2) • Variables: 1. IN(B) = set of definitions reaching the beginning of block B. 2. OUT(B) = set of definitions reaching the end of B. 16 Docsity.com Data-Flow Equations --- (3) • Two kinds of equations: 1. Confluence equations : IN(B) in terms of outs of predecessors of B. 2. Transfer equations : OUT(B) in terms of of IN(B) and what goes on in block B. 17 Docsity.com Example: Gen and Kill 20 d1: y = 3 d2: x = y+z d3: *p = 10 d4: y = 5 IN = {d2(x), d3(y), d3(z), d5(y), d6(y), d7(z)} Kill includes {d1(x), d2(x), d3(y), d5(y), d6(y),…} Gen = {d2(x), d3(x), d3(z),…, d4(y)} OUT = {d2(x), d3(x), d3(z),…, d4(y), d7(z)} Docsity.com Transfer Function for a Block • For any block B: OUT(B) = (IN(B) – Kill(B)) ∪ Gen(B) 21 Docsity.com Iterative Solution to Equations • For an n-block flow graph, there are 2n equations in 2n unknowns. • Alas, the solution is not unique. – Standard theory assumes a field of constants; sets are not a field. • Use iterative solution to get the least fixedpoint. – Identifies any def that might reach a point. 22 Docsity.com Aside: Notice the Conservatism • Not only the most conservative assumption about when a def is killed or gen’d. • Also the conservative assumption that any path in the flow graph can actually be taken. • Fine, as long as the optimization is triggered by limitations on the set of RD’s, not by the assumption that a def does not reach. 25 Docsity.com Another Data-Flow Problem: Available Expressions • An expression x+y is available at a point if no matter what path has been taken to that point from the entry, x+y has been evaluated, and neither x nor y have even possibly been redefined. • Useful for global common-subexpression elimination. 26 Docsity.com Equations for AE • The equations for AE are essentially the same as for RD, with one exception. • Confluence of paths involves intersection of sets of expressions rather than union of sets of definitions. 27 Docsity.com Transfer Equations • Transfer is the same idea: OUT(B) = (IN(B) – Kill(B)) ∪ Gen(B) 30 Docsity.com Confluence Equations • Confluence involves intersection, because an expression is available coming into a block if and only if it is available coming out of each predecessor. IN(B) = ∩predecessors P of B OUT(P) 31 Docsity.com Iterative Solution IN(entry) = ∅; for each block B do OUT(B)= ALL; while (changes occur) do for each block B do { IN(B) = ∩predecessors P of B OUT(P); OUT(B) = (IN(B) – Kill(B)) ∪ Gen(B); } 32 Docsity.com Subtle Point • It is conservative to assume an expression isn’t available, even if it is. • But we don’t have to be “insanely conservative.” – If after considering all paths, and assuming x+y killed by any possibility of redefinition, we still can’t find a path explaining its unavailability, then x+y is available. 35 Docsity.com Live Variable Analysis • Variable x is live at a point p if on some path from p, x is used before it is redefined. • Useful in code generation: if x is not live on exit from a block, there is no need to copy x from a register to memory. 36 Docsity.com Equations for Live Variables • LV is essentially a “backwards” version of RD. • In place of Gen(B): Use(B) = set of variables x possibly used in B prior to any certain definition of x. • In place of Kill(B): Def(B) = set of variables x certainly defined before any possible use of x. 37 Docsity.com