Principles of Program Analysis: Data Flow Analysis

Transcription

1 Principles of Program Analysis: Data Flow Analysis Transparencies based on Chapter 2 of the book: Flemming Nielson, Hanne Riis Nielson and Chris Hankin: Principles of Program Analysis. Springer Verlag c Flemming Nielson & Hanne Riis Nielson & Chris Hankin. PPA Chapter 2 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 1

2 Example Language Syntax of While-programs a ::= x n a 1 op a a 2 b ::= true false not b b 1 op b b 2 a 1 op r a 2 S ::= [x := a] l [skip] l S 1 ; S 2 if [b] l then S 1 else S 2 while [b] l do S Example: [z:=1] 1 ; while [x>0] 2 do ([z:=z*y] 3 ; [x:=x-1] 4 ) Abstract syntax parentheses are inserted to disambiguate the syntax PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 2

3 Building an Abstract Flowchart Example: [z:=1] 1 ; while [x>0] 2 do ([z:=z*y] 3 ; [x:=x-1] 4 ) init( ) = 1 [z:=1] 1 final( ) = {2} labels( ) = {1, 2, 3, 4} flow( ) = {(1, 2), (2, 3), (3, 4), (4, 2)} [x>0] 2 yes [z:=z*y] 3 no flow R ( ) = {(2, 1), (2, 4), (3, 2), (4, 3)} [x:=x-1] 4 PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 3

4 Initial labels init(s) is the label of the first elementary block of S: init : Stmt Lab init([x := a] l ) = l init([skip] l ) = l init(s 1 ; S 2 ) = init(s 1 ) init(if [b] l then S 1 else S 2 ) = l init(while [b] l do S) = l Example: init([z:=1] 1 ; while [x>0] 2 do ([z:=z*y] 3 ; [x:=x-1] 4 )) = 1 PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 4

5 Final labels final(s) is the set of labels of the last elementary blocks of S: final : Stmt P(Lab) final([x := a] l ) = {l} final([skip] l ) = {l} final(s 1 ; S 2 ) = final(s 2 ) final(if [b] l then S 1 else S 2 ) = final(s 1 ) final(s 2 ) final(while [b] l do S) = {l} Example: final([z:=1] 1 ; while [x>0] 2 do ([z:=z*y] 3 ; [x:=x-1] 4 )) = {2} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 5

6 Labels labels(s) is the entire set of labels in the statement S: labels : Stmt P(Lab) labels([x := a] l ) = {l} labels([skip] l ) = {l} labels(s 1 ; S 2 ) = labels(s 1 ) labels(s 2 ) labels(if [b] l then S 1 else S 2 ) = {l} labels(s 1 ) labels(s 2 ) labels(while [b] l do S) = {l} labels(s) Example labels([z:=1] 1 ; while [x>0] 2 do ([z:=z*y] 3 ; [x:=x-1] 4 )) = {1, 2, 3, 4} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 6

7 Flows and reverse flows flow(s) and flow R (S) are representations of how control flows in S: flow, flow R : Stmt P(Lab Lab) flow([x := a] l ) = flow([skip] l ) = flow(s 1 ; S 2 ) = flow(s 1 ) flow(s 2 ) {(l, init(s 2 )) l final(s 1 )} flow(if [b] l then S 1 else S 2 ) = flow(s 1 ) flow(s 2 ) {(l, init(s 1 )), (l, init(s 2 ))} flow(while [b] l do S) = flow(s) {(l, init(s))} {(l, l) l final(s)} flow R (S) = {(l, l ) (l, l) flow(s)} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 7

8 Elementary blocks A statement consists of a set of elementary blocks blocks : Stmt P(Blocks) blocks([x := a] l ) = {[x := a] l } blocks([skip] l ) = {[skip] l } blocks(s 1 ; S 2 ) = blocks(s 1 ) blocks(s 2 ) blocks(if [b] l then S 1 else S 2 ) = {[b] l } blocks(s 1 ) blocks(s 2 ) blocks(while [b] l do S) = {[b] l } blocks(s) A statement S is label consistent if and only if any two elementary statements [S 1 ] l and [S 2 ] l with the same label in S are equal: S 1 = S 2 A statement where all labels are unique is automatically label consistent PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 8

9 Intraprocedural Analysis Classical analyses: Available Expressions Analysis Reaching Definitions Analysis Very Busy Expressions Analysis Live Variables Analysis Derived analysis: Use-Definition and Definition-Use Analysis PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 9

10 Available Expressions Analysis The aim of the Available Expressions Analysis is to determine For each program point, which expressions must have already been computed, and not later modified, on all paths to the program point. Example: point of interest [x:= a+b ] 1 ; [y:=a*b] 2 ; while [y> a+b ] 3 do ([a:=a+1] 4 ; [x:= a+b ] 5 ) The analysis enables a transformation into [x:= a+b] 1 ; [y:=a*b] 2 ; while [y> x ] 3 do ([a:=a+1] 4 ; [x:= a+b] 5 ) PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 10

11 Available Expressions Analysis the basic idea X 1 X 2 N = X 1 X 2 x := a { kill }}{ X = (N\{expressions with an x} ) {subexpressions of a without an x} }{{} gen PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 11

12 Available Expressions Analysis kill and gen functions kill AE ([x := a] l ) = {a AExp x FV(a )} kill AE ([skip] l ) = kill AE ([b] l ) = gen AE ([x := a] l ) = {a AExp(a) x FV(a )} gen AE ([skip] l ) = gen AE ([b] l ) = AExp(b) AE entry (l) = data flow equations: AE = { if l = init(s ) {AEexit (l ) (l, l) flow(s )} otherwise AE exit (l) = (AE entry (l)\kill AE (B l )) gen AE (B l ) where B l blocks(s ) PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 12

13 Example: [x:=a+b] 1 ; [y:=a*b] 2 ; while [y>a+b] 3 do ([a:=a+1] 4 ; [x:=a+b] 5 ) kill and gen functions: l kill AE (l) gen AE (l) 1 {a+b} 2 {a*b} 3 {a+b} 4 {a+b, a*b, a+1} 5 {a+b} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 13

14 Example (cont.): [x:=a+b] 1 ; [y:=a*b] 2 ; while [y>a+b] 3 do ([a:=a+1] 4 ; [x:=a+b] 5 ) Equations: AE entry (1) = AE entry (2) = AE exit (1) AE entry (3) = AE exit (2) AE exit (5) AE entry (4) = AE exit (3) AE entry (5) = AE exit (4) AE exit (1) = AE entry (1) {a+b} AE exit (2) = AE entry (2) {a*b} AE exit (3) = AE entry (3) {a+b} AE exit (4) = AE entry (4)\{a+b, a*b, a+1} AE exit (5) = AE entry (5) {a+b} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 14

15 Example (cont.): [x:=a+b] 1 ; [y:=a*b] 2 ; while [y> a+b ] 3 do ([a:=a+1] 4 ; [x:=a+b] 5 ) Largest solution: l AE entry (l) AE exit (l) 1 {a+b} 2 {a+b} {a+b, a*b} 3 {a+b} {a+b} 4 {a+b} 5 {a+b} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 15

16 Why largest solution? [z:=x+y] l ; while [true] l do [skip] l Equations: AE entry (l) = AE entry (l ) = AE exit (l) AE exit (l ) AE entry (l ) = AE exit (l ) AE exit (l) = AE entry (l) {x+y} AE exit (l ) = AE entry (l ) [ ] l [ ] l AE exit (l ) = AE entry (l ) [ ] l yes no After some simplification: AE entry (l ) = {x+y} AE entry (l ) Two solutions to this equation: {x+y} and PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 16

17 Reaching Definitions Analysis The aim of the Reaching Definitions Analysis is to determine For each program point, which assignments may have been made and not overwritten, when program execution reaches this point along some path. Example: point of interest [x:=5] 1 ; [y:=1] 2 ; while [x>1] 3 do ([y:=x*y] 4 ; [x:=x-1] 5 ) useful for definition-use chains and use-definition chains PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 17

18 Reaching Definitions Analysis the basic idea X 1 X 2 N = X 1 X 2 [x := a] l { kill }}{ X = (N\{(x,?), (x, 1), } ) {(x, l)} }{{} gen PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 18

19 Reaching Definitions Analysis kill and gen functions kill RD ([x := a] l ) = {(x,?)} {(x, l ) B l is an assignment to x in S } kill RD ([skip] l ) = kill RD ([b] l ) = gen RD ([x := a] l ) = {(x, l)} gen RD ([skip] l ) = gen RD ([b] l ) = RD entry (l) = data flow equations: RD = { {(x,?) x FV(S )} if l = init(s ) {RDexit (l ) (l, l) flow(s )} otherwise RD exit (l) = (RD entry (l)\kill RD (B l )) gen RD (B l ) where B l blocks(s ) PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 19

20 Example: [x:=5] 1 ; [y:=1] 2 ; while [x>1] 3 do ([y:=x*y] 4 ; [x:=x-1] 5 ) kill and gen functions: l kill RD (l) gen RD (l) 1 {(x,?), (x, 1), (x, 5)} {(x, 1)} 2 {(y,?), (y, 2), (y, 4)} {(y, 2)} 3 4 {(y,?), (y, 2), (y, 4)} {(y, 4)} 5 {(x,?), (x, 1), (x, 5)} {(x, 5)} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 20

21 Example (cont.): [x:=5] 1 ; [y:=1] 2 ; while [x>1] 3 do ([y:=x*y] 4 ; [x:=x-1] 5 ) Equations: RD entry (1) = {(x,?), (y,?)} RD entry (2) = RD exit (1) RD entry (3) = RD exit (2) RD exit (5) RD entry (4) = RD exit (3) RD entry (5) = RD exit (4) RD exit (1) = (RD entry (1)\{(x,?), (x, 1), (x, 5)}) {(x, 1)} RD exit (2) = (RD entry (2)\{(y,?), (y, 2), (y, 4)}) {(y, 2)} RD exit (3) = RD entry (3) RD exit (4) = (RD entry (4)\{(y,?), (y, 2), (y, 4)}) {(y, 4)} RD exit (5) = (RD entry (5)\{(x,?), (x, 1), (x, 5)}) {(x, 5)} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 21

22 Example (cont.): Smallest solution: [x:=5] 1 ; [y:=1] 2 ; while [x>1] 3 do ([y:= x*y ] 4 ; [x:=x-1] 5 ) l RD entry (l) RD exit (l) 1 {(x,?), (y,?)} {(y,?), (x, 1)} 2 {(y,?), (x, 1)} {(x, 1), (y, 2)} 3 {(x, 1), (y, 2), (y, 4), (x, 5)} {(x, 1), (y, 2), (y, 4), (x, 5)} 4 {(x, 1), (y, 2), (y, 4), (x, 5)} {(x, 1), (y, 4), (x, 5)} 5 {(x, 1), (y, 4), (x, 5)} {(y, 4), (x, 5)} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 22

23 Why smallest solution? [z:=x+y] l ; while [true] l do [skip] l Equations: RD entry (l) = {(x,?), (y,?), (z,?)} RD entry (l ) = RD exit (l) RD exit (l ) RD entry (l ) = RD exit (l ) RD exit (l) = (RD entry (l) \ {(z,?)}) {(z, l)} RD exit (l ) = RD entry (l ) [ ] l [ ] l RD exit (l ) = RD entry (l ) [ ] l yes no After some simplification: RD entry (l ) = {(x,?), (y,?), (z, l)} RD entry (l ) Many solutions to this equation: any superset of {(x,?), (y,?), (z, l)} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 23

24 Very Busy Expressions Analysis An expression is very busy at the exit from a label if, no matter what path is taken from the label, the expression is always used before any of the variables occurring in it are redefined. The aim of the Very Busy Expressions Analysis is to determine For each program point, which expressions must be very busy at the exit from the point. Example: point of interest if [a>b] 1 then ([x:= b-a ] 2 ; [y:= a-b ] 3 ) else ([y:= b-a ] 4 ; [x:= a-b ] 5 ) The analysis enables a transformation into [t1:= b-a ] A ; [t2:= b-a ] B ; if [a>b] 1 then ([x:=t1] 2 ; [y:=t2] 3 ) else ([y:=t1] 4 ; [x:=t2] 5 ) PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 24

25 Very Busy Expressions Analysis the basic idea { kill }}{ N = (X\{all expressions with an x} ) {all subexpressions of a} }{{} gen x := a X = N 1 N 2 N 1 N 2 PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 25

26 Very Busy Expressions Analysis kill and gen functions kill VB ([x := a] l ) = {a AExp x FV(a )} kill VB ([skip] l ) = kill VB ([b] l ) = gen VB ([x := a] l ) = AExp(a) gen VB ([skip] l ) = gen VB ([b] l ) = AExp(b) VB exit (l) = data flow equations: VB = { if l final(s ) {VBentry (l ) (l, l) flow R (S )} otherwise VB entry (l) = (VB exit (l)\kill VB (B l )) gen VB (B l ) where B l blocks(s ) PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 26

27 Example: if [a>b] 1 then ([x:=b-a] 2 ; [y:=a-b] 3 ) else ([y:=b-a] 4 ; [x:=a-b] 5 ) kill and gen function: l kill VB (l) gen VB (l) 1 2 {b-a} 3 {a-b} 4 {b-a} 5 {a-b} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 27

28 Example (cont.): if [a>b] 1 then ([x:=b-a] 2 ; [y:=a-b] 3 ) else ([y:=b-a] 4 ; [x:=a-b] 5 ) Equations: VB entry (1) = VB exit (1) VB entry (2) = VB exit (2) {b-a} VB entry (3) = {a-b} VB entry (4) = VB exit (4) {b-a} VB entry (5) = {a-b} VB exit (1) = VB entry (2) VB entry (4) VB exit (2) = VB entry (3) VB exit (3) = VB exit (4) = VB entry (5) VB exit (5) = PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 28

29 Example (cont.): if [a>b] 1 then ([x:=b-a] 2 ; [y:=a-b] 3 ) else ([y:=b-a] 4 ; [x:=a-b] 5 ) Largest solution: l VB entry (l) VB exit (l) 1 {a-b, b-a} {a-b, b-a} 2 {a-b, b-a} {a-b} 3 {a-b} 4 {a-b, b-a} {a-b} 5 {a-b} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 29

30 Why largest solution? Equations: (while [x>1] l do [skip] l ); [x:=x+1] l VB entry (l) = VB exit (l) VB entry (l ) = VB exit (l ) VB entry (l ) = {x+1} VB exit (l) = VB entry (l ) VB entry (l ) VB exit (l ) = VB entry (l) [ ] l yes [ ] l no [ ] l VB exit (l ) = After some simplifications: VB exit (l) = VB exit (l) {x+1} Two solutions to this equation: {x+1} and PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 30

31 Live Variables Analysis A variable is live at the exit from a label if there is a path from the label to a use of the variable that does not re-define the variable. The aim of the Live Variables Analysis is to determine For each program point, which variables may be live at the exit from the point. Example: point of interest [ x :=2] 1 ; [y:=4] 2 ; [x:=1] 3 ; (if [y>x] 4 then [z:=y] 5 else [z:=y*y] 6 ); [x:=z] 7 The analysis enables a transformation into [y:=4] 2 ; [x:=1] 3 ; (if [y>x] 4 then [z:=y] 5 else [z:=y*y] 6 ); [x:=z] 7 PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 31

32 Live Variables Analysis the basic idea {}}{ kill N = (X\{x} ) {all variables of a} }{{} gen x := a X = N 1 N 2 N 1 N 2 PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 32

33 Live Variables Analysis kill and gen functions kill LV ([x := a] l ) = {x} kill LV ([skip] l ) = kill LV ([b] l ) = gen LV ([x := a] l ) = FV(a) gen LV ([skip] l ) = gen LV ([b] l ) = FV(b) LV exit (l) = data flow equations: LV = { if l final(s ) {LVentry (l ) (l, l) flow R (S )} otherwise LV entry (l) = (LV exit (l)\kill LV (B l )) gen LV (B l ) where B l blocks(s ) PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 33

34 Example: [x:=2] 1 ; [y:=4] 2 ; [x:=1] 3 ; (if [y>x] 4 then [z:=y] 5 else [z:=y*y] 6 ); [x:=z] 7 kill and gen functions: l kill LV (l) gen LV (l) 1 {x} 2 {y} 3 {x} 4 {x, y} 5 {z} {y} 6 {z} {y} 7 {x} {z} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 34

35 Example (cont.): [x:=2] 1 ; [y:=4] 2 ; [x:=1] 3 ; (if [y>x] 4 then [z:=y] 5 else [z:=y*y] 6 ); [x:=z] 7 Equations: LV entry (1) = LV exit (1)\{x} LV entry (2) = LV exit (2)\{y} LV entry (3) = LV exit (3)\{x} LV entry (4) = LV exit (4) {x, y} LV entry (5) = (LV exit (5)\{z}) {y} LV entry (6) = (LV exit (6)\{z}) {y} LV entry (7) = {z} LV exit (1) = LV entry (2) LV exit (2) = LV entry (3) LV exit (3) = LV entry (4) LV exit (4) = LV entry (5) LV entry (6) LV exit (5) = LV entry (7) LV exit (6) = LV entry (7) LV exit (7) = PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 35

36 Example (cont.): [x:=2] 1 ; [y:=4] 2 ; [x:=1] 3 ; (if [y>x] 4 then [z:=y] 5 else [z:=y*y] 6 ); [x:=z] 7 Smallest solution: l LV entry (l) LV exit (l) 1 2 {y} 3 {y} {x, y} 4 {x, y} {y} 5 {y} {z} 6 {y} {z} 7 {z} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 36

37 Why smallest solution? Equations: (while [x>1] l do [skip] l ); [x:=x+1] l LV entry (l) = LV exit (l) {x} LV entry (l ) = LV exit (l ) LV entry (l ) = {x} LV exit (l) = LV entry (l ) LV entry (l ) LV exit (l ) = LV entry (l) [ ] l yes [ ] l no [ ] l LV exit (l ) = After some calculations: LV exit (l) = LV exit (l) {x} Many solutions to this equation: any superset of {x} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 37

38 Derived Data Flow Information Use-Definition chains or ud chains: each use of a variable is linked to all assignments that reach it [x:=0] 1 ; [x:=3] 2 ; (if [z=x] 3 then [z:=0] 4 else [z:=x] 5 ); [y:= x ] 6 ; [x:=y+z] 7 Definition-Use chains or du chains: each assignment to a variable is linked to all uses of it [x:=0] 1 ; [ x :=3] 2 ; (if [z=x] 3 then [z:=0] 4 else [z:=x] 5 ); [y:=x] 6 ; [x:=y+z] 7 PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 38

39 ud chains ud : Var Lab P(Lab ) given by ud(x, l ) = {l def(x, l) l : (l, l ) flow(s ) clear(x, l, l )} {? clear(x, init(s ), l )} where [x:= ] l [ :=x] l }{{} no x:= def(x, l) means that the block l assigns a value to x clear(x, l, l ) means that none of the blocks on a path from l to l contains an assignments to x but that the block l uses x (in a test or on the right hand side of an assignment) PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 39

40 ud chains - an alternative definition is defined by: UD : Var Lab P(Lab ) UD(x, l) = { {l (x, l ) RD entry (l)} if x gen LV (B l ) otherwise One can show that: ud(x, l) = UD(x, l) PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 40

41 du chains given by du(x, l) = du : Var Lab P(Lab ) {l def(x, l) l : (l, l ) flow(s ) clear(x, l, l )} if l? {l clear(x, init(s ), l )} if l =? [x:= ] l [ :=x] l One can show that: }{{} no x:= du(x, l) = {l l ud(x, l )} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 41

42 Example: [x:=0] 1 ; [x:=3] 2 ; (if [z=x] 3 then [z:=0] 4 else [z:=x] 5 ); [y:=x] 6 ; [x:=y+z] 7 ud(x, l) x y z {2} {?} 4 5 {2} 6 {2} 7 {6} {4, 5} du(x, l) x y z 1 2 {3, 5, 6} 3 4 {7} 5 {7} 6 {7} 7? {3} PPA Section 2.1 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 42

43 Theoretical Properties Structural Operational Semantics Correctness of Live Variables Analysis PPA Section 2.2 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 43

44 The Semantics A state is a mapping from variables to integers: σ State = Var Z The semantics of arithmetic and boolean expressions A : AExp (State Z) (no errors allowed) B : BExp (State T) (no errors allowed) The transitions of the semantics are of the form S, σ σ and S, σ S, σ PPA Section 2.2 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 44

45 Transitions [x := a] l, σ σ[x A[[a]]σ] [skip] l, σ σ S 1, σ S 1, σ S 1 ; S 2, σ S 1 ; S 2, σ S 1, σ σ S 1 ; S 2, σ S 2, σ if [b] l then S 1 else S 2, σ S 1, σ if [b] l then S 1 else S 2, σ S 2, σ while [b] l do S, σ (S; while [b] l do S), σ while [b] l do S, σ σ if B[[b]]σ = true if B[[b]]σ = false if B[[b]]σ = true if B[[b]]σ = false PPA Section 2.2 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 45

46 Example: [y:=x] 1 ; [z:=1] 2 ; while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6, σ 300 [z:=1] 2 ; while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6, σ 330 while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6, σ 331 [z:=z*y] 4 ; [y:=y-1] 5 ; while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6, σ 331 [y:=y-1] 5 ; while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6, σ 333 while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6, σ 323 [z:=z*y] 4 ; [y:=y-1] 5 ; while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6, σ 323 [y:=y-1] 5 ; while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6, σ 326 while [y>1] 3 do ([z:=z*y] 4 ; [y:=y-1] 5 ); [y:=0] 6, σ 316 [y:=0] 6, σ 316 σ 306 PPA Section 2.2 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 46

47 Equations and Constraints Equation system LV = (S ): LV exit (l) = { if l final(s ) {LVentry (l ) (l, l) flow R (S )} otherwise LV entry (l) = (LV exit (l)\kill LV (B l )) gen LV (B l ) where B l blocks(s ) Constraint system LV (S ): LV exit (l) { if l final(s ) {LVentry (l ) (l, l) flow R (S )} otherwise LV entry (l) (LV exit (l)\kill LV (B l )) gen LV (B l ) where B l blocks(s ) PPA Section 2.2 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 47

48 Lemma Each solution to the equation system LV = (S ) is also a solution to the constraint system LV (S ). Proof: Trivial. Lemma The least solution to the equation system LV = (S ) is also the least solution to the constraint system LV (S ). Proof: Use Tarski s Theorem. Naive Proof: Proceed by contradiction. Suppose some LHS is strictly greater than the RHS. Replace the LHS by the RHS in the solution. Argue that you still have a solution. This establishes the desired contradiction. PPA Section 2.2 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 48

49 Lemma A solution live to the constraint system is preserved during computation S, σ 1 S, σ 1 S, σ 1 σ 1 = LV = LV = LV live live live Proof: requires a lot of machinery see the book. PPA Section 2.2 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 49

50 Correctness Relation σ 1 V σ 2 means that for all practical purposes the two states σ 1 and σ 2 are equal: only the values of the live variables of V matters and here the two states are equal. Example: Consider the statement [x:=y+z] l Let V 1 = {y, z}. Then σ 1 V1 σ 2 means σ 1 (y) = σ 2 (y) σ 1 (z) = σ 2 (z) Let V 2 = {x}. Then σ 1 V2 σ 2 means σ 1 (x) = σ 2 (x) PPA Section 2.2 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 50

51 Correctness Theorem The relation is invariant under computation: the live variables for the initial configuration remain live throughout the computation. S, σ 1 S, σ 1 S, σ 1 σ 1 V V V V S, σ 2 S, σ 2 S, σ 2 σ 2 V = live entry (init(s)) V = live entry (init(s )) V = live entry (init(s )) V = live exit (init(s )) = live exit (l) for some l final(s) PPA Section 2.2 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 51

52 Monotone Frameworks Monotone and Distributive Frameworks Instances of Frameworks Constant Propagation Analysis PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 52

53 The Overall Pattern Each of the four classical analyses take the form Analysis (l) = { ι if l E {Analysis (l ) (l, l) F } otherwise Analysis (l) = f l (Analysis (l)) where is or (and is or ), F is either flow(s ) or flow R (S ), E is {init(s )} or final(s ), ι specifies the initial or final analysis information, and f l is the transfer function associated with B l blocks(s ). PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 53

54 The Principle: forward versus backward The forward analyses have F to be flow(s ) and then Analysis concerns entry conditions and Analysis concerns exit conditions; the equation system presupposes that S has isolated entries. The backward analyses have F to be flow R (S ) and then Analysis concerns exit conditions and Analysis concerns entry conditions; the equation system presupposes that S has isolated exits. PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 54

55 The Principle: union versus intersecton When is we require the greatest sets that solve the equations and we are able to detect properties satisfied by all execution paths reaching (or leaving) the entry (or exit) of a label; the analysis is called a must-analysis. When is we require the smallest sets that solve the equations and we are able to detect properties satisfied by at least one execution path to (or from) the entry (or exit) of a label; the analysis is called a may-analysis. PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 55

56 Property Spaces The property space, L, is used to represent the data flow information, and the combination operator, : P(L) L, is used to combine information from different paths. L is a complete lattice, that is, a partially ordered set, (L, ), such that each subset, Y, has a least upper bound, Y. L satisfies the Ascending Chain Condition; that is, each ascending chain eventually stabilises (meaning that if (l n ) n is such that l 1 l 2 l 3,then there exists n such that l n = l n+1 = ). PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 56

57 Example: Reaching Definitions L = P(Var Lab ) is partially ordered by subset inclusion so is the least upper bound operation is and the least element is L satisfies the Ascending Chain Condition because Var Lab is finite (unlike Var Lab) PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 57

58 Example: Available Expressions L = P(AExp ) is partially ordered by superset inclusion so is the least upper bound operation is and the least element is AExp L satisfies the Ascending Chain Condition because AExp is finite (unlike AExp) PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 58

59 Transfer Functions The set of transfer functions, F, is a set of monotone functions over L, meaning that l l implies f l (l) f l (l ) and furthermore they fulfil the following conditions: F contains all the transfer functions f l : L L in question (for l Lab ) F contains the identity function F is closed under composition of functions PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 59

60 Frameworks A Monotone Framework consists of: a complete lattice, L, that satisfies the Ascending Chain Condition; we write for the least upper bound operator a set F of monotone functions from L to L that contains the identity function and that is closed under function composition A Distributive Framework is a Monotone Framework where additionally all functions f in F are required to be distributive: f(l 1 l 2 ) = f(l 1 ) f(l 2 ) PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 60

61 Instances An instance of a Framework consists of: the complete lattice, L, of the framework the space of functions, F, of the framework a finite flow, F (typically flow(s ) or flow R (S )) a finite set of extremal labels, E (typically {init(s )} or final(s )) an extremal value, ι L, for the extremal labels a mapping, f, from the labels Lab to transfer functions in F PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 61

62 Equations of the Instance: Analysis (l) = {Analysis (l ) (l, l) F } ι l E { where ι l ι if l E E = if l / E Analysis (l) = f l (Analysis (l)) Constraints of the Instance: Analysis (l) {Analysis (l ) (l, l) F } ι l E { where ι l ι if l E E = if l / E Analysis (l) f l (Analysis (l)) PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 62

63 The Examples Revisited Available Reaching Very Busy Live Expressions Definitions Expressions Variables L P(AExp ) P(Var Lab ) P(AExp ) P(Var ) AExp AExp ι {(x,?) x FV(S )} E {init(s )} {init(s )} final(s ) final(s ) F flow(s ) flow(s ) flow R (S ) flow R (S ) F {f : L L l k, l g : f(l) = (l \ l k ) l g } f l f l (l) = (l \ kill(b l )) gen(b l ) where B l blocks(s ) PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 63

64 Bit Vector Frameworks A Bit Vector Framework has L = P(D) for D finite F = {f l k, l g : f(l) = (l \ l k ) l g } Examples: Available Expressions Live Variables Reaching Definitions Very Busy Expressions PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 64

65 Lemma: Bit Vector Frameworks are always Distributive Frameworks Proof f(l 1 l 2 ) = = = { { f(l1 l 2 ) ((l1 l = 2 ) \ l k ) l g f(l 1 l 2 ) ((l 1 l 2 ) \ l k ) l { { g ((l1 \ l k ) (l 2 \ l k )) l g ((l1 \ l = k ) l g ) ((l 2 \ l k ) l g ) ((l 1 \ l k ) (l 2 \ l k )) l g ((l 1 \ l k ) l g ) ((l 2 \ l k ) l g ) { f(l1 ) f(l 2 ) = f(l f(l 1 ) f(l 2 ) 1 ) f(l 2 ) id(l) = (l \ ) f 2 (f 1 (l)) = (((l \ lk 1) l1 g ) \ l2 k ) l2 g = (l \ (l1 k l2 k )) ((l1 g \ l2 k ) l2 g ) monotonicity follows from distributivity P(D) satisfies the Ascending Chain Condition because D is finite PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 65

66 The Constant Propagation Framework An example of a Monotone Framework that is not a Distributive Framework The aim of the Constant Propagation Analysis is to determine For each program point, whether or not a variable has a constant value whenever execution reaches that point. Example: [x:=6] 1 ; [y:=3] 2 ; while [x > y ] 3 do ([x:=x 1] 4 ; [z:= y y ] 6 ) The analysis enables a transformation into [x:=6] 1 ; [y:=3] 2 ; while [x > 3] 3 do ([x:=x 1] 4 ; [z:=9] 6 ) PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 66

67 Elements of L State CP = ((Var Z ), ) Idea: is the least element: no information is available σ Var Z specifies for each variable whether it is constant: σ(x) Z: x is constant and the value is σ(x) σ(x) = : x might not be constant PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 67

68 Partial Ordering on L The partial ordering on (Var Z ) is defined by σ (Var Z ) : σ σ 1, σ 2 Var Z : σ 1 σ 2 iff x : σ 1 (x) σ 2 (x) where Z = Z { } is partially ordered as follows: z Z : z z 1, z 2 Z : (z 1 z 2 ) (z 1 = z 2 ) PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 68

69 Transfer Functions in F F CP = {f f is a monotone function on State CP } Lemma Constant Propagation as defined by Framework State CP and F CP is a Monotone PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 69

70 Instances Constant Propagation is a forward analysis, so for the program S : the flow, F, is flow(s ), the extremal labels, E, is {init(s )}, the extremal value, ι CP, is λx., and the mapping, f CP, of labels to transfer functions is as shown next PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 70

71 Constant Propagation Analysis : AExp ( State CP Z { ) if σ = A CP [[x]] σ = σ(x) otherwise { if σ = A CP [[n]] σ = n otherwise A CP A CP [[a 1 op a a 2 ]] σ = A CP [[a 1 ]] σ ôp a A CP [[a 2 ]] σ transfer functions: fl CP { [x := a] l : fl CP if σ = ( σ) = σ[x A CP [[a]] σ] otherwise [skip] l : [b] l : f CP l ( σ) = σ f CP l ( σ) = σ PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 71

72 Lemma Constant Propagation is not a Distributive Framework Proof Consider the transfer function f CP l for [y:=x*x] l Let σ 1 and σ 2 be such that σ 1 (x) = 1 and σ 2 (x) = 1 Then σ 1 σ 2 maps x to fl CP ( σ 1 σ 2 ) maps y to Both f CP l ( σ 1 ) and fl CP ( σ 2 ) map y to 1 fl CP ( σ 1 ) fl CP ( σ 2 ) maps y to 1 PPA Section 2.3 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 72

73 Equation Solving The MFP solution Maximum (actually least) Fixed Point Worklist algorithm for Monotone Frameworks The MOP solution Meet (actually join) Over all Paths PPA Section 2.4 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 73

74 The MFP Solution Idea: iterate until stabilisation. Worklist Algorithm Input: An instance (L, F, F, E, ι, f ) of a Monotone Framework Output: The MFP Solution: MFP, MFP Data structures: Analysis: the current analysis result for block entries (or exits) The worklist W: a list of pairs (l, l ) indicating that the current analysis result has changed at the entry (or exit) to the block l and hence the entry (or exit) information must be recomputed for l PPA Section 2.4 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 74

75 Worklist Algorithm Step 1 Step 2 Initialisation (of W and Analysis) W := nil; for all (l, l ) in F do W := cons((l, l ),W); for all l in F or E do if l E then Analysis[l] := ι else Analysis[l] := L ; Iteration (updating W and Analysis) while W nil do l := fst(head(w)); l = snd(head(w)); W := tail(w); if f l (Analysis[l]) Analysis[l ] then Analysis[l ] := Analysis[l ] f l (Analysis[l]); for all l with (l, l ) in F do W := cons((l, l ),W); Step 3 Presenting the result (MFP and MFP ) for all l in F or E do MFP (l) := Analysis[l]; MFP (l) := f l (Analysis[l]) PPA Section 2.4 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 75

76 Correctness The worklist algorithm always terminates and it computes the least (or MFP) solution to the instance given as input. Complexity Suppose that E and F contain at most b 1 distinct labels, that F contains at most e b pairs, and that L has finite height at most h 1. Count as basic operations the applications of f l, applications of, or updates of Analysis. Then there will be at most O(e h) basic operations. Example: Reaching Definitions (assuming unique labels): O(b 2 ) where b is size of program: O(h) = O(b) and O(e) = O(b). PPA Section 2.4 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 76

77 The MOP Solution Idea: propagate analysis information along paths. Paths The paths up to but not including l: path (l) = {[l 1,, l n 1 ] n 1 i < n : (l i, l i+1 ) F l n = l l 1 E} The paths up to and including l: path (l) = {[l 1,, l n ] n 1 i < n : (l i, l i+1 ) F l n = l l 1 E} Transfer functions for a path l = [l 1,, l n ]: f l = f ln f l1 id PPA Section 2.4 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 77

78 The MOP Solution The solution up to but not including l: MOP (l) = {f l (ι) l path (l)} The solution up to and including l: MOP (l) = {f l (ι) l path (l)} Precision of the MOP versus MFP solutions The MFP solution safely approximates the MOP solution: MF P MOP ( because f(x y) f(x) f(y) when f is monotone). For Distributive Frameworks the MFP and MOP solutions are equal: MF P = MOP ( because f(x y) = f(x) f(y) when f is distributive). PPA Section 2.4 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 78

79 Lemma Consider the MFP and MOP solutions to an instance (L, F, F, B, ι, f ) of a Monotone Framework; then: MFP MOP and MFP MOP If the framework is distributive and if path (l) for all l in E and F then: MFP = MOP and MFP = MOP PPA Section 2.4 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 79

80 Decidability of MOP and MFP The MFP solution is always computable (meaning that it is decidable) because of the Ascending Chain Condition. The MOP solution is often uncomputable (meaning that it is undecidable): the existence of a general algorithm for the MOP solution would imply the decidability of the Modified Post Correspondence Problem, which is known to be undecidable. PPA Section 2.4 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 80

81 Lemma The MOP solution for Constant Propagation is undecidable. Proof: Let u 1,, u n and v 1,, v n be strings over the alphabet {1,,9}; let u denote the length of u; let [[u]] be the natural number denoted. The Modified Post Correspondence Problem is to determine whether or not u i1 u im = v i1 v in for some sequence i 1,, i m with i 1 = 1. x:=[[u 1 ]]; y:=[[v 1 ]]; while [ ] do (if [ ] then x:=x * 10 u 1 + [[u 1 ]]; y:=y * 10 v 1 + [[v 1 ]] else. if [ ] then x:=x * 10 u n + [[u n ]]; y:=y * 10 v n + [[v n ]] else skip) [z:=abs((x-y)*(x-y))] l Then MOP (l) will map z to 1 if and only if the Modified Post Correspondence Problem has no solution. This is undecidable. PPA Section 2.4 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 81

82 Interprocedural Analysis The problem MVP: Meet over Valid Paths Making context explicit Context based on call-strings Context based on assumption sets (A restricted treatment; see the book for a more general treatment.) PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 82

83 The Problem: match entries with exits proc fib(val z, u; res v) is 1 [z<3] 2 yes no [call fib(x,0,y)] 9 10 [v:=u+1] 3 [call fib(z-1,u,v)] 4 5 [call fib(z-2,v,v)] 6 7 end 8 PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 83

84 Preliminaries Syntax for procedures Programs: Declarations: Statements: P = begin D S end D ::= D; D proc p(val x; res y) is l n S end l x S ::= [call p(a, z)] l c l r Example: begin proc fib(val z, u; res v) is 1 if [z<3] 2 then [v:=u+1] 3 else ([call fib(z-1,u,v)] 4 5 ; [call fib(z-2,v,v)]6 7 ) end 8 ; [call fib(x,0,y)] 9 10 end PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 84

85 Flow graphs for procedure calls init([call p(a, z)] l c l r ) = l c final([call p(a, z)] l c l r ) = {l r } blocks([call p(a, z)] l c l r ) = {[call p(a, z)] l c l r } labels([call p(a, z)] l c l r ) = {l c, l r } flow([call p(a, z)] l c l r ) = {(l c ; l n ), (l x ; l r )} if proc p(val x; res y) is ln S end lx is in D (l c ; l n ) is the flow corresponding to calling a procedure at l c and entering the procedure body at l n, and (l x ; l r ) is the flow corresponding to exiting a procedure body at l x and returning to the call at l r. PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 85

86 Flow graphs for procedure declarations For each procedure declaration proc p(val x; res y) is l n S end l x of D : init(p) = l n final(p) = {l x } blocks(p) = {is ln, end lx } blocks(s) labels(p) = {l n, l x } labels(s) flow(p) = {(l n, init(s))} flow(s) {(l, l x ) l final(s)} PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 86

87 Flow graphs for programs For the program P = begin D S end: init = init(s ) final = final(s ) blocks = {blocks(p) proc p(val x; res y) is ln S end lx is in D } blocks(s ) labels = {labels(p) proc p(val x; res y) is ln S end lx is in D } labels(s ) flow = {flow(p) proc p(val x; res y) is ln S end lx is in D } flow(s ) interflow = {(l c, l n, l x, l r ) proc p(val x; res y) is ln S end lx is in D and [call p(a, z)] l c l r is in S } PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 87

88 Example: We have begin proc fib(val z, u; res v) is 1 if [z<3] 2 then [v:=u+1] 3 else ([call fib(z-1,u,v)] 4 5 ; [call fib(z-2,v,v)]6 7 ) end 8 ; [call fib(x,0,y)] 9 10 end flow = {(1, 2), (2, 3), (3, 8), (2, 4), (4; 1), (8; 5), (5, 6), (6; 1), (8; 7), (7, 8), (9; 1), (8; 10)} interflow = {(9, 1, 8, 10), (4, 1, 8, 5), (6, 1, 8, 7)} and init = 9 and final = {10}. PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 88

89 A naive formulation Treat the three kinds of flow in the same way: Equation system: A (l) = f l (A (l)) flow treat as (l 1, l 2 ) (l 1, l 2 ) (l c ; l n ) (l c,l n ) (l x ; l r ) (l x,l r ) A (l) = {A (l ) (l, l) F or (l,l) F or (l,l) F } ι l E But there is no matching between entries and exits. PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 89

90 MVP: Meet over Valid Paths Complete Paths We need to match procedure entries and exits: A complete path from l 1 to l 2 in P has proper nesting of procedure entries and exits; and a procedure returns to the point where it was called: CP l1,l 2 l 1 whenever l 1 = l 2 CP l1,l 3 l 1, CP l2,l 3 CP lc,l l c, CP ln,l x, CP lr,l whenever (l 1, l 2 ) flow whenever P contains [call p(a, z)] l c l r and proc p(val x; res y) is l n S end l x More generally: whenever (l c, l n, l x, l r ) is an element of interflow (or interflow R for backward analyses); see the book. PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 90

91 Valid Paths A valid path starts at the entry node init of P, all the procedure exits match the procedure entries but some procedures might be entered but not yet exited: VP VP init,l whenever l Lab VP l1,l 2 l 1 whenever l 1 = l 2 VP l1,l 3 l 1, VP l2,l 3 VP lc,l l c, CP ln,l x, VP lr,l VP lc,l l c, VP ln,l whenever (l 1, l 2 ) flow whenever P contains [call p(a, z)] l c l r and proc p(val x; res y) is l n S end l x whenever P contains [call p(a, z)] l c l r and proc p(val x; res y) is l n S end l x PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 91

92 The MVP solution MVP (l) = {f l (ι) l vpath (l)} MVP (l) = {f l (ι) l vpath (l)} where vpath (l) = {[l 1,, l n 1 ] n 1 l n = l [l 1,, l n ] is a valid path} vpath (l) = {[l 1,, l n ] n 1 l n = l [l 1,, l n ] is a valid path} The MVP solution may be undecidable for lattices satisfying the Ascending Chain Condition, just as was the case for the MOP solution. PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 92

93 Making Context Explicit Starting point: an instance (L, F, F, E, ι, f ) of a Monotone Framework the analysis is forwards, i.e. F = flow and E = {init }; the complete lattice is a powerset, i.e. L = P( D ); the transfer functions in F are completely additive; and each f l is given by f l (Y ) = { φ l (d) d Y } where φ l : D P(D). (A restricted treatment; see the book for a more general treatment.) PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 93

94 An embellished monotone framework L = P( D ); the transfer functions in F are completely additive; and each f l is given by f l (Z) = { {δ} φ l (d) ( δ, d ) Z}. Ignoring procedures, the data flow equations will take the form: A (l) = f l (A (l)) for all labels that do not label a procedure call A (l) = {A (l ) (l, l) F or (l ; l) F } ι l E for all labels (including those that label procedure calls) PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 94

95 Example: Detection of Signs Analysis as a Monotone Framework: (L sign, F sign, F, E, ι sign, f sign ) where Sign = {-, 0, +} and L sign = P( Var Sign ) The transfer function f sign l associated with the assignment [x := a] l is where Y Var Sign and f sign l (Y ) = { φ sign l (σ sign ) σ sign Y } φ sign l (σ sign ) = {σ sign [x s] s A sign [[a]](σ sign )} PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 95

96 Example (cont.): Detection of Signs Analysis as an embellished monotone framework L sign = P( (Var Sign) ) The transfer function associated with [x := a] l will now be: f sign sign l (Z) = { {δ} φ l (σ sign ) ( δ, σ sign ) Z} PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 96

97 Transfer functions for procedure declarations Procedure declarations proc p(val x; res y) is ln S end l x have two transfer functions, one for entry and one for exit: f ln, f lx : P( D ) P( D ) For simplicity we take both to be the identity function (thus incorporating procedure entry as part of procedure call, and procedure exit as part of procedure return). PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 97

98 Transfer functions for procedure calls Procedure calls [call p(a, z)] l c l r have two transfer functions: For the procedure call and it is used in the equation: f 1 l c : P( D ) P( D ) A (l c ) = f 1 l c (A (l c )) for all procedure calls [call p(a, z)] l c l r For the procedure return f 2 l c,l r : P( D ) P( D ) P( D ) and it is used in the equation: A (l r ) = f 2 l c,l r ( A (l c ), A (l r )) for all procedure calls [call p(a, z)] l c l r (Note that A (l r ) will equal A (l x ) for the relevant procedure exit.) PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 98

99 Procedure calls and returns proc p(val x; res y) Z fl 1 c (Z) is l n Z f 2 l c,l r (Z, Z ) [call p(a, z)] l c l r 2 Z end l x PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 99

100 Variation 1: ignore calling context upon return proc p(val x; res y) [call p(a, z)] l c fl 1 1 is l n [call p(a, z)] lr 2 fl 2 c,l r end l x f 1 l c (Z) = {{δ } φ 1 l c (d) (δ, d) Z δ = δ d Z } f 2 l c,l r (Z, Z ) = f 2 l r (Z ) PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 100

101 Variation 2: joining contexts upon return proc p(val x; res y) [call p(a, z)] l c f 2A l c,l r [call p(a, z)] l5 fl 1 c 2 fl 2B c,l r is l n end l x f 1 l c (Z) = {{δ } φ 1 l c (d) (δ, d) Z δ = δ d Z } f 2 l c,l r (Z, Z ) = f 2A l c,l r (Z) f 2B l c,l r (Z ) PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 101

102 Different Kinds of Context Call Strings contexts based on control Call strings of unbounded length Call strings of bounded length (k) Assumption Sets contexts based on data Large assumption sets (k = 1) Small assumption sets (k = 1) PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 102

103 Call Strings of Unbounded Length = Lab Transfer functions for procedure call f 1 l c (Z) = {{δ } φ 1 l c (d) (δ, d) Z δ = [δ, l c ]} f 2 l c,l r (Z, Z ) = {{δ} φ 2 l c,l r (d, d ) (δ, d) Z (δ, d ) Z δ = [δ, l c ]} PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 103

104 Example: Recalling the statements: proc p(val x; res y) is ln S end l x [call p(a, z)] l c l r Detection of Signs Analysis: φ sign1 l c (σ sign ) = {σ sign initialise formals {}}{ [x s][y s ] s A sign [[a]](σ sign ), s {-, 0, +}} φ sign2 l c,l r (σ sign 1, σsign 2 ) = {σsign 2 [x σsign 1 (x)][y σsign 1 (y) ][z σ sign 2 (y) ]} } {{ } restore formals }{{} return result PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 104

105 Call Strings of Bounded Length = Lab k Transfer functions for procedure call f 1 l c (Z) = {{δ } φ 1 l c (d) (δ, d) Z δ = δ, l c k } f 2 l c,l r (Z, Z ) = {{δ} φ 2 l c,l r (d, d ) (δ, d) Z (δ, d ) Z δ = δ, l c k } PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 105

106 A special case: call strings of length k = 0 = {Λ} Note: this is equivalent to having no context information! Specialising the transfer functions: f 1 l c (Y ) = {φ 1 l c (d) d Y } f 2 l c,l r (Y, Y ) = {φ 2 l c,l r (d, d ) d Y d Y } (We use that P( D) isomorphic to P(D).) PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 106

107 A special case: call strings of length k = 1 = Lab {Λ} Specialising the transfer functions: f 1 l c (Z) = {{l c } φ 1 l c (d) (δ, d) Z} f 2 l c,l r (Z, Z ) = {{δ} φ 2 l c,l r (d, d ) (δ, d) Z (l c, d ) Z } PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 107

108 Large Assumption Sets (k = 1) = P(D) Transfer functions for procedure call f 1 l c (Z) = {{δ } φ 1 l c (d) (δ, d) Z δ = { d (δ, d ) Z}} f 2 l c,l r (Z, Z ) = {{δ} φ 2 l c,l r (d, d ) (δ, d) Z (δ, d ) Z δ = { d (δ, d ) Z}} PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 108

109 Small Assumption Sets (k = 1) = D Transfer function for procedure call f 1 l c (Z) = {{ d } φ 1 l c (d) (δ, d ) Z} f 2 l c,l r (Z, Z ) = {{δ} φ 2 l c,l r (d, d ) (δ, d) Z (d, d ) Z } PPA Section 2.5 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 109

110 Shape Analysis Goal: to obtain a finite representation of the shape of the heap of a language with pointers. The analysis result can be used for detection of pointer aliasing detection of sharing between structures software development tools detection of errors like dereferences of nil-pointers program verification reverse transforms a non-cyclic list to a non-cyclic list PPA Section 2.6 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 110

111 Syntax of the pointer language Example a ::= p n a 1 op a a 2 nil p ::= x x.sel b ::= true false not b b 1 op b b 2 a 1 op r a 2 op p p S ::= [p:=a] l [skip] l S 1 ; S 2 if [b] l then S 1 else S 2 while [b] l do S [malloc p] l [y:=nil] 1 ; while [not is-nil(x)] 2 do ([z:=y] 3 ; [y:=x] 4 ; [x:=x.cdr] 5 ; [y.cdr:=z] 6 ); [z:=nil] 7 PPA Section 2.6 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 111

112 Reversal of a list 0: x y z ξ 1 cdr ξ 2 cdr ξ 3 cdr ξ 4 cdr ξ 5 cdr 1: x y z ξ 2 ξ 1 cdr cdr ξ 3 cdr ξ 4 cdr ξ 5 cdr 2: x y z ξ 3 ξ 2 cdr cdr ξ 4 ξ 1 cdr cdr ξ 5 cdr 3: x y z ξ 4 ξ 3 cdr cdr ξ 5 ξ 2 cdr cdr ξ 1 cdr 4: x y z ξ 5 ξ 4 cdr cdr ξ 3 cdr ξ 2 cdr ξ 1 cdr 5: x y z ξ 5 cdr ξ 4 cdr ξ 3 cdr ξ 2 cdr ξ 1 cdr PPA Section 2.6 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 112

113 Structural Operational Semantics A configurations consists of a state σ State = Var (Z + Loc + { }) mapping variables to values, locations (in the heap) or the nil-value a heap H Heap = (Loc Sel) fin (Z + Loc + { }) mapping pairs of locations and selectors to values, locations in the heap or the nil-value PPA Section 2.6 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 113

114 Pointer expressions is defined by : PExp (State Heap) fin (Z + { } + Loc) [[x]](σ, H) = σ(x) [[x.sel]](σ, H) = H(σ(x), sel) if σ(x) Loc and H is defined on (σ(x), sel) undefined otherwise Arithmetic and boolean expressions A : AExp (State Heap) fin (Z + Loc + { }) B : BExp (State Heap) fin T PPA Section 2.6 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 114

115 Statements Clauses for assignments: [x:=a] l, σ, H σ[x A[[a]](σ, H)], H if A[[a]](σ, H) is defined [x.sel:=a] l, σ, H σ, H[(σ(x), sel) A[[a]](σ, H)] if σ(x) Loc and A[[a]](σ, H) is defined Clauses for malloc: [malloc x] l, σ, H σ[x ξ], H where ξ does not occur in σ or H [malloc (x.sel)] l, σ, H σ, H[(σ(x), sel) ξ] where ξ does not occur in σ or H and σ(x) Loc PPA Section 2.6 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 115

116 Shape graphs The analysis will operate on shape graphs (S, H, is) consisting of an abstract state, S, an abstract heap, H, and sharing information, is, for the abstract locations. The nodes of the shape graphs are abstract locations: ALoc = {n X X Var } Note: there will only be finitely many abstract locations PPA Section 2.6 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 116

117 Example Abstract Locations In the semantics: x ξ 3 cdr ξ 4 cdr ξ 5 cdr The abstract location n X represents the location σ(x) if x X y z ξ 2 cdr In the analysis: x n {x} cdr y n {y} cdr ξ 1 cdr cdr n n {z} The abstract location n is called the abstract summary location: n represents all the locations that cannot be reached directly from the state without consulting the heap Invariant 1 If two abstract locations n X and n Y occur in the same shape graph then either X = Y or X Y = z PPA Section 2.6 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 117

118 Abstract states and heaps S AState = P(Var ALoc) abstract states H AHeap = P(ALoc Sel ALoc) abstract heap x n {x} cdr y n {y} cdr z cdr n n {z} Invariant 2 If x is mapped to n X by the abstract state S then x X Invariant 3 Whenever (n V, sel, n W ) and (n V, sel, n W ) are in the abstract heap H then either V = or W = W PPA Section 2.6 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 118

119 Reversal of a list 0: x n {x} cdr cdr n 1: x n {x} cdr y n {y} cdr n 2: x n {x} cdr y n {y} cdr z cdr n n {z} 3: x n {x} cdr y n {y} cdr z n n {z} cdr 4: x n {x} y n {y} cdr z n n {z} cdr cdr 5: y n {y} cdr z n n {z} cdr cdr PPA Section 2.6 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 119

120 Sharing in the heap x y ξ 1 cdr ξ 2 cdr ξ 3 cdr ξ 4 ξ 5 cdr cdr x y ξ 1 cdr ξ 2 ξ 4 cdr cdr ξ 3 ξ 5 cdr cdr Give rise to the same shape graph: x n {x} cdr y n {y} cdr cdr n is: the abstract locations that might be shared due to pointers in the heap: n X is included in is if it might represents a location that is the target of more than one pointer in the heap PPA Section 2.6 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 120

121 Examples: sharing in the heap x y ξ 1 cdr ξ 2 cdr ξ 3 cdr ξ 4 ξ 5 cdr cdr x n {x} cdr y n {y} cdr cdr n x y ξ 1 cdr ξ 2 ξ 4 cdr cdr ξ 3 ξ 5 cdr cdr x n {x} cdr y n {y} cdr cdr n x y ξ 2 ξ 1 cdr ξ 3 cdr cdr ξ 4 ξ 5 cdr cdr x n {x} y cdr n {y} cdr cdr n PPA Section 2.6 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 121

122 Sharing information The implicit sharing information of the abstract heap must be consistent with the explicit sharing information: x n {x} y cdr n {y} cdr cdr n Invariant 4 If n X is then either (n, sel, n X ) is in the abstract heap for some sel, or there are two distinct triples (n V, sel 1, n X ) and (n W, sel 2, n X ) in the abstract heap Invariant 5 Whenever there are two distinct triples (n V, sel 1, n X ) and (n W, sel 2, n X ) in the abstract heap and X then n X is PPA Section 2.6 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 122

123 The complete lattice of shape graphs A shape graph is a triple (S,H,is) where S AState = P(Var ALoc) H AHeap = P(ALoc Sel ALoc) is IsShared = P(ALoc) and ALoc = {n Z Z Var }. A shape graph (S, H, is) is compatible if it fulfils the five invariants. The analysis computes over sets of compatible shape graphs SG = {(S, H, is) (S, H, is) is compatible} PPA Section 2.6 c F.Nielson & H.Riis Nielson & C.Hankin (May 2005) 123