EDA045F: Program Analysis LECTURE 3: DATAFLOW ANALYSIS 2. Christoph Reichenbach

Transcription

1 EDA045F: Program Analysis LECTURE 3: DATAFLOW ANALYSIS 2 Christoph Reichenbach

2 In the last lecture... Eliminating Nested Expressions (Three-Address Code) Control-Flow Graphs Static Single Assignment Form Basic Dataflow Analysis transb (x) mergeb (x, y) Reaching Definitions Analysis Live Variables Analysis 2 / 64

3 Dataflow Analysis Analyse properties of variables or basic blocks Examples in practice: Live Variables Is this variable ever read? Reaching Definitions What are the possible values for this variable? Available Expressions What variable definitely has which expression? 3 / 64

4 Analyses on Powersets (1/2) = {1} {2} {3} {1, 2} {1, 3} {2, 3} merge b = {1, 2, 3} = Common: Which elements of S are possible / necessary? S Z (Reaching Definitions) S = Numeric Constants in code {0, 1} S = Variables (Live Variables) S = Program Locations (alt. Reaching Definitions) S = Types Abstract Domain: Powerset P(S) Finite iff S is finite 4 / 64

5 Analyses on Powersets (2/2) = {1, 2, 3} = {1} {2} {3} {1, 2} {1, 3} {2, 3} {1, 2} {1, 3} {2, 3} {1} {2} {3} {1, 2, 3} = merge b = mergeb can be or : Property that is true over any path May-analysis (e.g., Reaching Definitions) : Property that is true over all paths = merge b = Must-analysis 5 / 64

6 Gen-Sets and Kill-Sets Many transfer functions transb have the following form: Remove set of options killx,b from each variable x Add set of options genx,b to each variable x Don t depend on other variables trans b ({x A,...}) = {x (A \ kill x,b ) gen x,b,...} Highly efficient implementation with bit-vectors possible Examples: Reaching Definitions on finite domain gen: assignments in current basic block kill: everything else if variable is assigned Live Variables gen: used variables kill: overwritten variables 6 / 64

7 Gen/Kill: Available Expressions Which expressions do we currently have evaluated and stored? C int x = 3 + z; int y = 2 + z; if (z > 0) { x = 4; } f(2 + z); // Can re-use y here! Forward analysis gen: any expression assigned to the variable kill: any other expression mergeb = 7 / 64

8 Gen/Kill: Very Busy Expressions Which expression do we definitely need to evaluate at least once? C // (x / 42) is very busy: (A),(B) if (z > 0) { x = 4 + x / 42; // (A) y = 1; } else { x = x / 42; // (B) } g(x); Backwards analysis gen: any expression assigned to the variable kill: any other expression mergeb = 8 / 64

9 Summary Common: Abstract Domain is powerset of some set S Transfer function transb : trans b ({x A,...}) = {x (A \ kill x,b ) gen x,b,...} kill: Kill set : Entries of S to remove gen: Gen set : Entries of S to add mergeb is or Often admits very efficient implementation May Must Forward Reaching Definitions Available Expressions Backward Live Variables Very Busy Expressions 9 / 64

10 Lattices: Models for Information Program analyses model information Undecidability = must approximate Conservative: over-approximate (contradictory information) Optimistic: under-approximate (incomplete information) Commonly used formal model: lattices 10 / 64

11 Partial Ordering Lattices L are based on a partially ordered set L, : Set: L describes possible information ( ) L L: Intuition for a b (for program analysis): a has at least as much information as b ( ) is a partial order: Example: a a a b and b a = a = b a b and b c = a c L = {unknown, true, false, true-or-false} true-or-false true unknown Reflexivity Antisymmetry Transitivity true-or-false false unknown 12 / 64

12 Greatest Lower bound a c b d Combining potentially contradictory information: Meet operator: ( ) : L L L a b a and a b b Greatest element with this property: for all d : d a and d b = d a b computes Greatest Lower Bound (Infimum) 13 / 64

13 Least Upper Bound d a c b Converse operation: Join operator: ( ) : L L L a a b and b a b Least element with this property: for all d : a d and a d = d a b computes Least Upper Bound (Supremum) 14 / 64

14 Lattices L = L,,, L: Underlying set ( ) L L: Partial Order ( ) : L L L: Meet (computes g.l.b.) ( ) : L L L: Join (computes l.u.b.) Join/Meet always exist and are unique It can be shown that ( ), ( ) are: Commutative: Associative: (Analogous for ) a b = b a a (b c) = (a b) c 15 / 64

15 Complete Lattices A lattice L = L,,, is complete iff: For any L L there exist: L (least upper bound for arbitrary set) L (greatest lower bound for arbitrary set) We define a for all a L as: = L We define a for all a L as: = L 16 / 64

16 Complete Lattices: Visually a n = a b = c a b n a b = d a n = 17 / 64

17 Example: Binary Lattice true = true = false = logical or false = logical and 18 / 64

18 Example: Booleans true false = true-and-false = true-or-false a b: must be both a and b a b: could be either a or b If B = {true, false}: Lattice sometimes called B Other interpretations possible 19 / 64

19 Example: Flat Lattice on Integers Sometimes written Z = = Z { a iff a = b a b = otherwise { a iff a = b a b = otherwise Analogous for other X from set X 20 / 64

20 Example: Type Hierarchy Lattices java.lang.object= Number Comparable OutputStream Integer Byte String Type systems with subtyping form (non-powerset) lattice Must add element Some langugaes (C++) need extra element For extra precision, we may add nodes for e.g. java.lang.comparable java.lang.serializable 21 / 64

21 Example: Powersets Take any set S = {a, b, c} {a} {b} {c} {a, b} {a, c} {b, c} L = P(S) = = S ( ) = ( ) ( ) = ( ) 22 / 64

22 Example: Lattices and Non-Lattices {a,b,c} PQ 1 {a,b} {b,c} P Q 0 {a} {b} {c} R S Lattice Lattice Not A Lattice Z Right-hand side is missing e.g. a unique R S 23 / 64

23 Example: Natural numbers with 0, ω ω 3 2 = ω = 0 a b = maximum of a and b a b = minimum of a and b / 64

24 Dual Lattices Let L = L,,, be a lattice. Then: L = L,,, is also a lattice L is dual lattice to L If L is complete, with L, L being top, bottom: L is also complete, and: L = L L = L Lattices can be flipped around without losing their properties 25 / 64

25 Product Lattices Program analysis: Each variable needs its own lattice Can we combine these lattices to analyse variables simultaneously? Assume (complete) lattices: L1 = L 1, 1, 1, 1, 1, 1 L2 = L 2, 2, 2, 2, 2, 2 Let L1 L 2 = L 1 L 2,,,,, where: a, b a, b iff a 1 a and b 2 b a, b a, b = a 1 a, b 2 b a, b a, b = a 1 a, b 2 b = 1, 2 = 1, 2 Point-wise products of (complete) lattices are again (complete) lattices 26 / 64

26 Product Lattices over Binary Lattices Recall binary lattices: = true = false true true true = logical or = logical and Computer hardware can compute, of multiple false false false lattices in parallel: Bitwise or/and = Highly efficient Can represent other lattices efficiently, too Give rise to highly efficient Gen-/Kill-Set based program analysis 27 / 64

27 Omitted Formal Details What we didn t cover: Partially Ordered Sets (Posets) Semi-lattices (lacking meet or join) Lattice absorption laws Many interesting lattice properties Not a full introduction to lattice theory 28 / 64

28 Word of Caution Definition in the book flips lattices and mean the opposite We use the more common definition from the research literature Definition is isomorphic, but can be confusing / 64

29 Summary Complete lattices are formal basis for many program analyses Complete lattice L = L,,,,, L: Carrier set ( ): Partial order ( ): Meet operation: find greatest lower bound (Analysis: merge b ) ( ): Join operation: find least upper bound (Analysis: uncommon, but can improve precision of two conservative results) : Top-most element of complete lattice (Analysis: I don t know ) : Bottom-most element of complete lattice (Analysis: I know that I can t know ) Lattices can be flipped Lattices can be combined into product lattices 30 / 64

30 Monotone Frameworks A Z L = L,,, is complete lattice Order: : No information (yet) : Too much information / could be anything mergeb (x, y) = x y for all b transb monotonic: x y = trans b (x) trans b (y) Finite lattice height ( Descending Chain Condition): x 0 x 1 x 2 x 3... = exists k s.th. for all k > k, x k = x k L can be infinite only the lattice height must be finite 31 / 64

31 Putting It All Together Monotone Frameworks ensure termination of Data Flow Analysis Information from complete Lattice L: : No information (yet) : Too much information / could be anything Must satisfy Descending Chain Condition: no infinite progress Ensure that no analysis step loses knowledge: Each basic block has transfer function transb Output knowledge out b from input knowledge in b Monotonic: increasing input knowledge does not decrease output knowledge Merging multiple inputs with mergeb = is lattice meet (greatest lower bound) 32 / 64

32 Fixpoints Algorithm sketch from last week: Repeat transb and merge b until value no longer moves Fixpoint Multiple possible solutions, ordered by Maximal Fixpoint Highest Precision 33 / 64

33 Value Range Analysis Find value range (interval of possible values) for x Python x = 1 while...: if...: x = 4 else: x = 7 Multiple possible sound solutions: [1, 7] [1, 10] [ 99, 99] All of these values are fixpoints [1, 7] is maximum fispoint 34 / 64

34 An Algorithm for MFP Last week: sketched naive algorithm for computing fixpoint Produces maximum fixpoint (MFP) Optimise processing with worklist Set-like datastructure: add element (if not already present) contains check: is element present? pop element: remove and return one element Tracks what s left to be done 35 / 64

35 The MFP Algorithm Procedure MFP(, merge,, CFG, trans, is-backward): begin if is-backward then reverse edges(cfg); worklist := edges(cfg); -- edges that we need to look at foreach n nodes(cfg) do analysis[n] = ; -- state of the analysis done while not empty(worklist) do n, n := pop(worklist); if analysis[n ] trans n (analysis[n]) then begin analysis[n ] := merge n (analysis[n ], trans n (analysis[n])); foreach n successor-nodes(cfg, n ) do push(worklist, n, n ); done end done return analysis; end Worklist allows focussing effort! 36 / 64

36 Summary: MFP Algorithm Compute data flow analysis: Initialise all nodes with Repeat until nothing changes any more: Apply transfer function Propagate changes along control flow graph Apply Compute maximal fixpoint Use worklist to increase efficiency Distinction: Forward/Backward analyses 37 / 64

37 Another Dataflow Example Consider again Reaching Definitions: Lattice: : Unknown : Too much/contradictory information Integer: exactly that one assignment is possible 38 / 64

38 Optimal Dataflow Results x = 3 y = 1 z = true b 0 if (...) b 1 x = 3 b 2 y = 1 b 3 out b1 out b2 = x = y = z = z = x + y x = y = z = false x = 1 y = 3 x = 1 y = 3 z = x = y = z = Imprecise! Can we do better? 39 / 64

39 Execution paths b 0 if (...) b 1 x = 3 b 2 y = 1 x = 1 y = 3 b 3 z = x + y Idea: Let s consider all paths through the program: path b0 = {[]} path b1 = {[b 0 ]} path b2 = {[b 0 ]} path b3 = {[b 0, b 1 ], [b 0, b 2 ]} 40 / 64

40 The MOP algorithm for Dataflow Analysis Compute the MOP ( meet-over-all-paths ) solution: Iterate over all paths [p0,..., p k ] in path bi Compute precise result for that path Merge ( ) with all other precise results out bi = trans bi trans pk trans p0 ( ) [p 0,...,p k ] path bi Notation: (function composition) (f g)(x) = f (g(x)) 41 / 64

41 MOP vs MFP: Example b 0 if (...) b 1 x = 3 b 2 y = 1 x = 1 y = 3 b 3 z = x + y Transfer functions Paths trans b0 = id trans b1 = [x 3][y 1] trans b2 = [x 1][y 3] trans b3 = [z x + y] path b0 = {[]} path b1 = {[b 0 ]} path b2 = {[b 0 ]} path b3 = {[b 0, b 1 ], [b 0, b 2 ]} out b3 = ([z x + y][x 3][y 1]( )) ([z x + y][x 1][y 3]( )) = {z 3 + 1, x 3, y 1} {z 1 + 3, x 1, y 3} = {z 4, x, y } 42 / 64

42 MOP vs MFP MOP MFP Soundness sound sound Precision maximal sometimes lower Decidability undecidable decidable MOP: Meet Over all Paths MFP: Maximal Fixed Point 43 / 64

43 Summary pathb : Set of all paths from program start to b MOP: alternative to MFP (theoretically) Termination not guaranteed May be more precise Idea: Enumerate all paths to basic block Compute transfer functions over paths individually Meet 44 / 64

44 MFP revisited Consider Reaching Definitions again, with different lattice: x = 0 y = 0 z = 1 l 0 l 1 l 2 = {l 0 } {l 1 } {l 2 } {l 3 } {l 4 } x = x + 1 l 3 {l 0, l 1 } {l 3, l 4 } = {l 0, l 1, l 2, l 3, l 4 } y = 7 l 4 z = y All subsets of {l0,..., l 4 } Finite height return x, y, z = 45 / 64

45 MFP revisited: Transfer Functions b 0 x = 0 y = 0 z = 1 b 1 l 0 l 1 l 2 x = x + 1 l 3 b 2 b 3 y = 7 z = y l 4 trans b0 =[ x {l 0 }, y {l 1 }, z {l 2 }] trans b1 =[x {l 3 }] trans b2 =[y {l 4 }] trans b3 =[z y] b 4 return x, y, z 46 / 64

46 MOP vs MFP revisited Solutions for b 4 : MOP solution x {l 0, l 3 } y {l 1, l 4 } z {l 1, l 2, l 4 } MFP solution x {l 0, l 3 } y {l 1, l 4 } z {l 1, l 2, l 4 } Repeat with other programs: MOP solution always the same as MFP solution Not true for other lattices/transfer functions / 64

47 Distributive Frameworks A Monotone Framework is: Lattice L = L,,, L has finite height (Descending Chain Condition) All transb are monotonic Guarantees that MFP conservatively approximates MOP A Distributive Framework is: A Monotone Framework, where additionally: transb distributes over : trans b (x y) = trans b (x) trans b (y) for all programs and all x, y, b Guarantees that MFP is equal to MOP 48 / 64

48 Distributive Problems Monotonic: trans b (x y) trans b (x) trans b (y) Distributive: trans b (x y) = trans b (x) trans b (y) Many analyses can fit distributive framework Known counter-example: transfer functions on Z : [z x + y] Generally: transfer function that depends on two independent inputs and may produce same output for different inputs 49 / 64

49 A Hack to Improve Precision 1 (1/2) b 0 if (...) b 1 true x = 3 y = 1 b 2 false x = 1 y = 3 b 3 z = x + y Recall: Imprecision comes about because trans b3 (out b1 out b2 ) = trans b3 ({x 3, y 1,...} {x 1, y 3,...}) = trans b3 ({x, y,...}) = {z,...} Idea: Transfer first, then meet: trans b3 ({x 3, y 1,...}) trans b3 ({x 1, y 3,...}) = {z 4,...} {z 4,...} 50 / 64

50 A Hack to Improve Precision (2/2) b 0 if (...) b 1 true x = 3 y = 1 b 2 false x = 1 y = 3 b 3 a = 0 b 4 z = x + y in b4 = out b3 = trans b3 ({x 3, y 1,...}) trans b3 ({x 1, y 3,...}) = {x 3, y 1,...} {x 1, y 3,...} = {x, y,...} Only works if data is used right at point of the merge 51 / 64

51 Summary Distributive Frameworks are Monotone Frameworks with additional property: trans b (x y) = trans b (x) trans b (y) for all programs and all x, y, b In Distributive Frameworks, MOP and MFP produce same answer Gen/Kill-set based analyses are always distributive 52 / 64

52 Subroutine calls name ::= id id. id val ::= name num expr ::= val val + val null print val new() id ( val ) stmt ::= name = expr { stmt } if val stmt else stmt while val stmt skip return val decl ::= proc id ( id ) stmt global id = num prog ::= decl 53 / 64

53 Limitations of Intra-Procedural Analysis ATL a = 7 d = f(a, 2) e = a + d ATL proc f(x, y) { z = 0 if x > y { z = x } else { z = y } return z } How can we compute Reachable Definitions here? 54 / 64

54 A Naive Inter-Procedural Analysis b c 6 b 5 a = 7 d = f(a, 2) a {7} (return) b r 6 x {7} y {2} f(x, y) = z = 0 if... b 0 b 1 b 2 z = x z = y b 3 b 7 e = a + d d {2, 7} return z b 4 omitting obvious transfer functions in b r 6 = out b6 out b4 = out b r 6 outb7 : e {9, 14} Works rather straightforwardly! 55 / 64

55 Inter-Procedural Data Flow Analysis b c x e = f(1, 5) subroutine start ENTER b r x (return) EXIT subroutine end Split call sites bx into call (bx c ) and return (bx) r nodes Intra-procedural edge b c x bx r carries environment/store Inter-procedural edge ( ): Caller subroutine, substitutes parameters (for pass-by-value) Caller return, substitutes result (for pass-by-result) Otherwise as intra-procedural data flow edge 56 / 64

56 A Naive Inter-Procedural Analysis b c 6 b 5 a = 7 d = f(a, 2) x {7} y {2} x {1} y {5} f(x, y) = z = 0 if... b 0 b 1 x {1, 7} y {2, 5} (return) b r 6 b 2 z = x z = y b 3 b c 7 e = f(1, 5) d {1, 2, 5, 7} return z b 4 z {1, 2, 5, 7} (return) b r 7 e {1, 2, 5, 7} Imprecision! 57 / 64

57 Context Sensitivity: Valid Paths b c 6 b 5 a = 7 d = f(a, 2) z = 0 if... b 0 b 1 b c 7 b r 6 e = f(1, 5) b r 7 (return) (return) b 2 z = x z = y b 3 return z b 4 Not Not a valida valid path path either [b5, b c 6, b 0, b 1, b 3, b 4, b r 6] Context-sensitive analyses consider only valid paths 58 / 64

58 Summary Intraprocedural Data Flow Analysis is highly imprecise with subroutine calls Interprocedural Data Flow Analysis is more precise: Split call site into call site + return site Add flow edges between call sites, subroutine entry Add flow edges between subroutine return, return site Carry environment from call site to return site Interprocedural analysis must typically consider the entire program whole-program analysis Naive interprocedural analysis is context-insensitive Merge all callers into one 59 / 64

59 Interprocedural Data Flow Analysis b c 6 b 5 a = 7 d = f(a, 2) x {7} y {2} x {1} y {5} f(x, y) = z = 0 if... b 0 b 1 x {1, 7} y {2, 5} (return) b r 6 b 2 z = x z = y b 3 b c 7 e = f(1, 5) d {2, 7, 1, 5} return z b 4 z {1, 2, 5, 7} (return) b r 7 e {1, 5, 2, 7} Context-insensitive: analysis merges all callers to f() 60 / 64

60 Inlining a = 7 x {7} y {2} f(x, y) = z = 0 b c 6 b c 7 d = f(a, 2) (return) b r 6 e = f(1, 5) d {2, 7} z = x if... return z z = y (return) b r 7 x {1} y {5} z = 0 if... e {1, 5} z = x return z z = y Clone subroutine IRs for each calling context 61 / 64

61 Summary Context-sensitive analysis distinguishes calling context when analysing subroutine Who called me? Can go deeper: And who called them? Inlining is one strategy for context-sensitive analysis Copy subroutine bodies for each caller Advantages: Simple Improves precision Disadvantages: Difficult with recursion Slows down analysis 62 / 64

62 Review Gen/Kill analyses Lattices Monotone Frameworks MFP algorithm MOP algorithm Distributive Frameworks Interprocedural Analysis Inlining for analysis 63 / 64

63 To be continued... Next week: More on IFDS and its refinements Callgraph Analysis 64 / 64