1. Course Outline Traditional Static Program Analysis –Theory Compiler Optimizations; Control Flow Graphs Data-flow Analysis: Data-flow frameworks –Classic analyses and applications Software Testing Dynamic Program Analysis

2. Announcements Homework 1 Homework 2 –Due Monday, February 28 th –A few notes on homework CS accounts should be ready

3. Outline Data-flow frameworks –Monotone frameworks –Distributive frameworks –A Non-distributive example: Points-to Analysis –The “Maximal Fixed Point” (MFP) solution –The “Meet Over all Paths” (MOP) solution –Analysis safety (correctness) and Analysis precision Reading: Compilers: Principles, Techniques and Tools, by Aho, Lam, Sethi and Ullman, Chapter 9.3

4. Monotone Dataflow Frameworks Generic data-flow equations: in(i) = V out(m) out(i) = f i (in(i)) Parameters: –Property space: in(i), out(i) are elements of a property space Combination operator V: U for may problems and ∩ for must problems Initial values set to the 0 (smallest element) of the property space –Transfer functions: f i is associated with node i –If we instantiate these parameters in a certain way, then our analysis is an instance of the monotone dataflow framework m in pred(i)

5. Monotone Frameworks: Requirements The property space is a complete lattice L under partial order ≤ where L satisfies the Ascending Chain Condition –The combination operator V –Initial values set to the 0 of L The transfer functions: f i : L  L Each f i is monotone

6. Monotonicity A function f is monotone iff (1) a ≤ b f(a) ≤ f(b) or equivalently (2) f(x) V f(y)≤ f(x V y)

7. Distributivity A function f is distributive iff f(x) V f(y) = f(x V y) A distributive framework: A monotone framework with distributive transfer functions: f(x) V f(y) = f(x V y) The 4 classical dataflow problems are instances of a distributive framework

8. Points-to Analysis: a fundamental analysis. It computes the memory locations that a pointer variable may point to Example 1: int a, b; int *p1, *p2; p1 = &a; p2 = p1; *p2 = 1; Points-to Analysis Example 2: int a, b = 15; int *p1, *p2; int **p3; p3 = &p1; p1 = &a; p2 = *p3; *p2 = b;

9. Points-to Analysis: Monotone, Non- distributive Analysis Lattice: The set of all points-to graphs Pt ≤ is inclusion, Pt1 ≤ Pt2 if Pt1 is a subgraph of Pt2 V is union, P1 V P2 = P1 U P2 Transfer functions are defined on four kinds of statements: –(1) f(p=&q) is “kill” all points-to edges from p, and “generate a new points-to edge from p to q –(2) f(p=q) is “kill” all points-to edges from p, and “generate” new points-to edges from p to every x such that q points-to x –(3) f(p=*q) is “kill” all points-to edges from p, and “generate” new points to edges from p to every x, such that there exists y and q points to y and y points to x –(4) f(*p=q) Do not perform kill. Can you think of a reason why? “Generate” new points-to edges from every y to every x, such that p points to y and q points to x.

10. Monotone non-distributive Analysis First, we show that the framework is monotone, –I.e., for each of the four transfer functions we have to show that if Pt1 ≤ Pt2, then f(Pt1) ≤ f(Pt2) Second, we show that the framework is not distributive –It is easy to show f(Pt1 V Pt2) ≠ f(Pt1) V f(Pt2) Another example is constant propagation

11. Non-distributivity of Points-to Analysis p=&x; q=&y; p=&z; q=&w; *p=q pq xy Pt1: pq zw Pt2: pq xy f(Pt1): pq zw f(Pt2): f(Pt1) V f(Pt2) : pq xy zw Pt1 V Pt2 : pq xy zw pq xy zw f(Pt1 V Pt2): What f does: Adds edges from each variable that p points to (i.e., x and z), to each variable where q points to (i.e., y and w). 4 new edges: from x to y and w, and from z to y and w.

12. The Maximal Fixed Point (MFP) 1 /* Initialize to initial values */ in(1)=InitialValue; in(1) = UNDEF for m := 2 to n do in(m) := 0; i n(m) := Ø W := {1,2,…,n} /* put every node on the worklist */ while W ≠ Ø do { remove i from W; out(i) = f i (in(i)); out RD (i) = in RD (i)∩pres(i) U gen(i) for j in successors(i) if out(i) ≤ in(j) then { if out RD (i) not subset of in RD (j) in(j) = out(i) V in(j); in RD (j) = out(i) U in RD (j) if j not in W do add j to W } 1. The Least Fixed Point (LFP) actually…

13. Properties of the algorithm Lemma1: The algorithm terminates. Sketch of the proof: We have in k (j) ≤ in k+1 (j) and since L has ACC, in(j) changes at most O(h) times. Thus, each j is put on W at most O(h) times (h is the height of the lattice L). Complexity: At each iteration, the analysis examines e(j) out edges. Thus, number of basic operations is bounded by h*(e(1) out +…+e(N) out )=O(h*E). We can do better on reducible graphs.

14. Properties of the Algorithm Lemma2: The algorithm computes the least solution of the dataflow equations. –For every node i MFP computes solution MFP(i) = {in(i),out(i)}, such that every other solution {in’(i),out’(i)} of the dataflow equations is “larger” than the MFP Lemma3: The algorithm computes a correct (safe) solution.

15. Example 1. z:=x+y 2. if (z > 500) 3. skip in AE (2) = out AE (1) V out AE (3) in out (3) = out AE (2) in AE (1) = Ø out AE (2) = in AE (2) out AE (3) = in AE (3) out AE (1) = (in AE (1)-E z ) {x+y} Equivalent to: in AE (2) = {x+y} V in AE (2) and recall that V is ∩ (i.e., set intersection). Solution1Solution2 Ø {x+y} Ø Ø Ø That is why we needed to initialize in AE (2) and the other initial values to the universal set of expressions (0 of the Available Expressions lattice), rather than to the more intuitive empty set.

16. Meet Over All Paths (MOP) Solution 1 Desired dataflow information at n is obtained by traversing ALL PATHS from ρ to n. For every path p=(ρ, n 1, n 2..., n k ) we compute f n k (…f n 2 (f n 1 (init(ρ)))) The MOP at entry of n is V f n k (…f n 2 (f n 1 (init(ρ)))) The MOP is the best summary of dataflow facts possible to compute with this static analysis … ρ n1n1 n2n2 nknk p in paths from ρ to n n

17. MOP vs. MFP For distributive functions the dataflow analysis can merge paths (p1, p2), without loss of precision! –E.g., f p1 (0) need not be calculated explicitly –MFP=MOP Due to Kam and Ullman, 1976,1977: This is not true for monotone functions. Lemma 3: The MFP approximates the MOP for general monotone functions: MFP ≥ MOP

18. Safety of Dataflow Solution Safe (also, correct or sound) solution overestimates the best possible dataflow solution, i.e., x ≥ MOP is an approximate solution Acceptable solution is better than what we can do with the MFP, i.e., x ≤ MFP Between MOP and MFP are interesting solutions 0 MOP MFP Safe Acceptable

19. Safe Solutions In Available Expressions the 1 is the empty set, and the combination operator is set intersection. –It is safe to err by saying that an expression is NOT AVAILABLE when it might be. –We compute a smaller set. Thus, under our definition of ≤, this solution is larger than the MOP. In Reaching Definitions the 1 is the universal set of definitions, the combination is the union. –It is safe to err by saying that a definition reaches a node when in fact it DOES NOT REACH the node. –We compute a larger set. Thus, under our definition of ≤ (which is natural), the solution is larger than the MOP

20. Two Views of Reaching Definitions 0 element MOP/MFP Safe solutions are here; they are larger sets of definitions. Join semi-lattice formulation. We used this formulation. Defs

21. Two Views of Reaching Definitions Ø def1…defk Defs. 1 element MOP/MFP Safe solutions are larger sets of definitions than MOP Meet semi-lattice formulation

22. Kam and Ullman Results On monotone dataflow frameworks, iterative algorithms converge to the MFP of the dataflow equations (our Lemmas 1 and 2) MOP ≤ MFP (in our join formulation) (our Lemma 3) One monotone framework that is not distributive is constant propagation The MOP is undecidable for an arbitrary instance of a monotone framework.

23. Many Applications! White-box testing: compute coverage –Control-flow-based testing –Data-flow-based testing Intuitively, test each def-use chain Regression testing –Analyze changes and select regression tests that actually test changed code

24. Many Applications! Reverse engineering –UML class diagrams –UML sequence diagrams –Many tools do these; Eclipse plug-ins Automated refactoring –Analyze program, prove “safety” of the refactoring –Eclipse plug-ins

25. Many Applications! Static debugging –Memory errors in C/C++ programs Memory leaks Null pointer dereferences Array-out-of-bound accesses –Concurrency errors in shared-memory apps Data-races Atomicity violations Deadlocks