COP 5021 Lecture -*- Outline -*- * Monotone Frameworks (2.3) Q: Can we identify some commonalities between different analyses? yes... (as we'll see), but draw them out of the students Q: Would doing that help implement them? yes! ** general pattern A_. means A with a subscript of a filled circle A_o means A with a subscript of a hollow circle ------------------------------------------ GENERAL PATTERN A_o(l) = if l \in E then i else A_.(l) = where \bigsqcup is either \bigcup or \bigcap F is either flow(S*) or flow^R(S*) E is {init(S*)} or final(S*) i is initial/final information f(l) is the transfer function for blocks B^l \in blocks(S*) For a may analysis: \bigsqcup is For a must analysis: \bigsqcup is For a forward analysis: F is flow(S*) E is A_o gives the entry conditions A_. gives the exit conditions For a backward analysis: F is flow^R(S*) E is A_o gives the exit conditions A_. gives the entry conditions ------------------------------------------ ... \bigsqcup {A_.(l') | (l',l) \in F} ... f(l)(A_o(l)) ... \bigcup (union), when the property space is sets ... \bigcap (intersection), when the property space is sets ... {init(S*)} ... final(S*) The book writes f(l) as f_l. The transfer functions are key, and depend on the block in question, like the kill and gen functions did previously. ** basic definitions (2.3.1) *** property space ------------------------------------------ PROPERTY SPACES def (p. 65): a *property space*, L = (L, \bigsqcup), is a set with \bigsqcup: Powerset(L) -> L a join operation (\sqcup) that makes it a complete lattice. Thus: l1 \sqcup l2 = \bigsqcup { l1, l2 } \bot = \bigsqcup {} l1 \sqsubseteq l2 = (l1 \sqcup l2 = l2) Examples: For reaching definitions: L = Powerset(Var* x Lab^?_*) \sqcup = \cup \sqsubseteq = \subseteq For available expressions: L = Powerset(AExp*) \sqcup = \cap \sqsubseteq = \supseteq ------------------------------------------ We use property spaces for recording analysis information. **** lattice theory ***** partial orders, lub, joins, lattices Now we'll explain the term "complete lattice" ------------------------------------------ POSETS, LUBS, AND LATTICES (APPENDIX A) def: A *partially ordered set (poset)* is a pair (L, <=) of a set, L, together and a binary relation, <=, on L such that for all x,y,z in L: (reflexive) x <= x, (antisymmetric) x <= y and y <= x implies x = y, (transitive) x <= y and y <= z implies x <= z. def: for all x,y,u in L, u is an *upper bound of x and y* iff x <= u and y <= u. def: for all x,y,u in L, u is the *least upper bound of x and y* written lub(x,y) = u iff u is an upper bound of x and y and z such that z is an upper bound of x and y, u <= z. def: For all X, Y in L, the *join of X and Y*, is X \sqcup Y = lub(X,Y). This is also written as sup(X,Y). ------------------------------------------ A partial ordering is also called a "semiordering" or an "order relation" Q: does the lub of two elements x,y in L need to be in the set L? Yes! In general we can define \sqcup and \sqsubseteq in terms of each (x \sqcup y) = y iff x \sqsubseteq y Property: x \sqcup x = x ------------------------------------------ LATTICES, COMPLETE LATTICES (2.3.1, A.1-2) def: A *lattice* is a poset in which each pair of elements has a least upper bound. def: A *complete lattice* is a lattice L such that every nonempty subset of L has a least upper bound (in L). ------------------------------------------ Q: So, what is a property space? It's a complete lattice! Example of a lattice: (Powerset({a, b, c}), \subseteq) For this lattice, the ordering \sqsubseteq is the same as \subseteq: x \sqsubseteq y iff x \subseteq y Example that is a lattice but NOT a complete lattice: (Integers, <=), because the set of all positive number has no least upper bound in the set. Notation: for a set S \subseteq L, we write lub S (or sup S or \bigsqcup S) to mean the least upper bound of all x in S def: \bot (_|_) is lub({}) Property: for all x in L, \bot \sqsubseteq x ***** meets, glbs ------------------------------------------ GLBS and COMPLETE LATTICES (APPENDIX A) Assume (L, <=) is a poset. def: for all x,y,n in L, n is a *lower bound of x and y* iff n <= x and n <= y. def: for all x,y,n in L, n is the *greatest lower bound of x and y* written glb(x,y) = n iff n is a lower bound of x and y and for all z such that z is a lower bound of x and y, z <= n. def: For all X, Y in L, the *meet of X and Y*, is X \sqcap Y = glb(X,Y). This is also written as inf(X,Y). Thm: If (L, \sqsubseteq) is a lattice, then the following hold for all x, y, z in L: (commutative) x \sqcup y = y \sqcup x, (associative) x \sqcup (y \sqcup z) = (x \sqcup y) \sqcup z, (absoption) x \sqcup (y \sqcap x) = (x \sqcup y) \sqcap x = x ------------------------------------------ Notation \top (T) is defined by \top = \bigsqcap L Property, for all x in L, x \sqsubseteq \top **** chains and the ascending chain condition Sometimes we also require that a property space satisfy the ascending chain condition... as this ensures that fixed points always exist which is helpful in an implementation Implementations construct chains as they build better and better approximations to solve dataflow equations or constraints, since x \sqsubseteq y means y is more precise than x, (or x approximates y) ------------------------------------------ CHAINS, ASCENDING CHAIN CONDITION (A.3) def: A subset Y of a poset (L,\sqsubseteq) is a *chain* iff for all l_1, l_2 in Y, l_1 \sqsubseteq l_2 or l_2 \sqsubseteq l_1 def: An *ascending chain* in L is a sequence (l_n)_{n \in N} such that each l_i in L and for all n,m <= N, n <= m ==> l_n \sqsubseteq l_m. def: a sequence (l_n)_{n \in N} *stabilizes* iff there is some number n0 such that for all n >= n0, l_n = l_n0. def: L *satisfies the ascending chain condition* iff every ascending chain in L eventually stabilizes. def: a *domain* is a lattice that satisfies the ascending chain condition. ------------------------------------------ Domains, sometimes called cpos, are useful in programming language semantics. Q: If a chain is finite, does it stabilize? Yes (take n0 to be the size of the chain) Q: Is it necessary for lattice to be finite in order to satisfy the ascending chain condition? No. Lemma: Cartesian products preserve the property of satisfying the ascending chain cnodition. Lemma: If S is a finite lattice and L is a lattice that satisfies the ascending chain condition, then the function space S -> L satisfies the ascending chain condition Note that this is not necessarily true if S is not finite... *** transfer functions ------------------------------------------ TRANSFER FUNCTION SPACE def: Let L be a partially-ordered set. Then Funs is a *transfer function space for L* iff f \in Funs ==> f : L -> L and f is monotone, f,g \in Funs ==> f o g \in Funs, and id_L \in Funs. ------------------------------------------ *** monotone framework ------------------------------------------ MONOTONE FRAMEWORK def: (L, Funs) is a monotone framework iff L is a property space and Funs is a transfer function space for L. def: (L, Funs, F, E, i, f_.) is an *instance of a monotone framework* if and only if: - (L, Funs) is a monotone framework, - F is a finite set of pairs (of flows), - E is a finite set of extremal labels, - i \in L is an extremal value, - f : (dom(F) \cup E) -> (L -> L) s.t. for l in (dom(F) \cup E) f_l \in Funs ------------------------------------------ The first argument, the label, to the transfer functions is written as a subscript. ** examples (2.3.2) See figure 2.6 for a systematic presentation of the 4 analyses we've seen so far. ** predicate abstraction (new topic) Suppose we're concerned with the values of variables. ------------------------------------------ PREDICATE ABSTRACTION Goal: verify program properties Idea: Use property space of the form L = Powerset(Preds) Preds = {P1, ..., Pn} where each Pi is a nullary predicate Interpretation: {P3,P5} means P3 and P5 may (must) be true (depending on kind of analysis) \sqcup is \cup (or \cap) \sqsubseteq is \subseteq (or \supseteq) Funs = monotonic (in \sqsubseteq) functions on L ------------------------------------------ Q: For a may analysis, what's the bottom element? The top? {}, {P1, ..., Pn} Q: How can you represent states? with bit vectors ------------------------------------------ PREDICATE ABSTRACTION EXAMPLE IsZero Analysis: At a given program point, which variables may be 0. "Abstract States" s \in L = Powerset(Preds) where Preds = {IsZero_x | x in Vars*} IsZero_y means y may be 0 F is flow(S*) E is {init(S*)} i is Preds fIZ(l) : L -> L, for l in Lab* fIZ(l)(s) = (s \ kill_IZ(B^l)(s)) \cup gen_IZ(B^l)(s) where B^l in blocks(S*) kill_IZ([x := a]^l)(s) = {IsZero_x} kill_IZ([skip]^l)(s) = {} kill_IZ([b]^l)(s) = {} gen_IZ([x := a]^l)(s) = {IsZero_x | (\exists cs \in \gamma(s) :: A[[a]]cs == 0)} gen_IZ([skip]^l)(s) = {} gen_IZ([b]^l)(s) = {} \gamma: L -> Store \gamma(s) = {cs | cs: Var* -> Int, IsZero_x \in s ==> cs(x) == 0} ------------------------------------------ Q: What kind of analysis is this? A forward, may analysis; so \bot is {} Q: Why this initial value i? because it's what we know least information about (it's safe but not precise, as is correct for a may analysis) Q: What do the gen and kill functions do? Q: What are the equations for IZ_entry(l) and IZ_exit(l)? IZ_entry(l) = if l \in {init(S*)} then Preds else \bigcup {IZ_exit(l') | (l',l) \in flow(S*)} IZ_exit(l) = fIZ(l)(IZ_entry(l)) ------------------------------------------ EXAMPLE [y := 3]^1; while [y>0]^2 do ([q := y-2]^3; [y := y-1]^4); [q := q div y]^5 Var* = {y, q} Preds = {IsZero_y, IsZero_q} IZ_entry(1) = IZ_exit(1) = IZ_entry(2) = IZ_exit(2) = IZ_entry(3) = IZ_exit(3) = IZ_entry(4) = IZ_exit(4) = IZ_entry(5) = IZ_exit(5) = ------------------------------------------ ... IZ_entry(1) = {IsZero_q, IsZero_y} IZ_exit(1) = {IsZero_q} IZ_entry(2) = {IsZero_q} \cup IZ_exit(4) IZ_exit(2) = {IsZero_q} \cup IZ_exit(4) IZ_entry(3) = {IsZero_q} \cup IZ_exit(4) IZ_exit(3) = {IsZero_q} \cup IZ_exit(4) IZ_entry(4) ={IsZero_q} \cup IZ_exit(4) IZ_exit(4) = {IsZero_q} \cup {IsZero_y} IZ_entry(5) = {IsZero_q, IsZero_y} IZ_exit(5) = {IsZero_q, IsZero_y} Then by chaotic iteration you can see that most are {IsZero_q, IsZero_y} ** equation solving (2.4) *** MFP (Maximal Fixed Point) solution (2.4.1) See table 2.8 This is a work list algorithm that always terminates and computes the least solution to an instance of a monotone framework. (Lemma 2.29) The least solution is thus called the MFP solution (even though MFP stands for "maximal fixed point", because historically studied must analyses where \sqcup is \cap) The running time is approximately cubic in the number of program labels. *** MOP solution (2.4.2) (skip) propagates information over all paths in the program a MOP solution is always safely approximated by the MFP (least) solution, so the MOP solution is not always correct! always possible to use MFP, and MOP isn't always comparable, so MOP isn't very interesting...