Intra-procedural Data Flow Analysis Backwards analyses

Transcription

1 Live variables Dead code elimination Very Busy Expressions Code hoisting Bitvector frameworks Monotone frameworks Intra-procedural Data Flow Analysis Backwards analyses Hanne Riis Nielson and Flemming Nielson Informatics and Mathematical Modelling Technical University of Denmark c Hanne Riis Nielson & Flemming Nielson c HRN&FN (cf. slide 2) October 28,

2 Copyright This set of transparencies is mainly based on Flemming Nielson, Hanne Riis Nielson, Chris Hankin: Principles of Program Analysis. Springer, 1999; ISBN They may be used by instructors for presentations based on the book but may not be copied and distributed electronically or by other means. A handout version with four slides per page may be used for producing paper copies of the slides for students; the students may be charged no fee beyond reasonable production cost. The handout version of the transparancies is available from the webpage riis/ppa.htm. c HRN&FN (cf. slide 2) October 28,

3 Summary: Forward analyses Summary: Forward analyses [x := a] l A (l) A (l) [...] l 1 [...] l k [...] l A (l 1 ) A (l k ) A (l) A (l) = (A (l)\kill A (B l )) gen A (B l ) where B l blocks(s ) ι A if l = init(s ) A (l) = A {A (l ) (l, l) flow(s )} otherwise where A RD AE ι A {(x,?) x FV(S )} A c HRN&FN (cf. slide 2) October 28,

4 Live variables 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 c HRN&FN (cf. slide 2) October 28,

5 Live variables The basic idea LV (l) [x := a] l LV (l) Analysis information: [...] l LV (l) [...] l 1 [...] l 2 LV (l 1 ) LV (l 2 ) LV (l): the variables that are live at the entry of block l LV (l): the variables that are live at at the exit of block l kill LV (l): the variables that are killed by an elementary block gen LV (l): the variables that are generated by an elementary block c HRN&FN (cf. slide 2) October 28,

6 Live variables Analysis of elementary blocks Definition of the set of variables that are killed by an elementary block (i.e. they are no longer used in the future) and the set of variables that are generated by the block (they may be used in the future): 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) c HRN&FN (cf. slide 2) October 28,

7 Live variables Analysis of programs LV (l) [x := a] l LV (l) = LV (l) [...] l LV (l) [...] l 1 [...] l 2 LV (l 1 ) LV (l 2 ) Var if l final(s ) {LV (l ) (l, l) flow R (S )} otherwise LV (l) = (LV (l)\kill LV (B l )) gen LV (B l ) where B l blocks(s ) c HRN&FN (cf. slide 2) October 28,

8 Live variables 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 Equations: LV (1) = LV (1)\{x} LV (2) = LV (2)\{y} LV (3) = LV (3)\{x} LV (4) = LV (4) {x, y} LV (5) = (LV (5)\{z}) {y} LV (6) = (LV (6)\{z}) {y} LV (7) = {z} LV (1) = LV (2) LV (2) = LV (3) LV (3) = LV (4) LV (4) = LV (5) LV (6) LV (5) = LV (7) LV (6) = LV (7) LV (7) = Analysis of elementary blocks: 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} Smallest solution: l LV (l) LV (l) 1 2 {y} 3 {y} {x, y} 4 {x, y} {y} 5 {y} {z} 6 {y} {z} 7 {z} c HRN&FN (cf. slide 2) October 28,

9 Live variables Why smallest solution? while [x>1] l do [skip] l od; [x:=x+1] l Equations: LV (l) = LV (l) {x} LV (l ) = LV (l ) LV (l ) = {x} LV (l) = LV (l ) LV (l ) LV (l ) = LV (l) [x>1] l yes [skip] l no [x:=x+1] l LV (l ) = {x} After some calculations: LV (l) = LV (l) {x} Many solutions to this equation: any superset of {x} c HRN&FN (cf. slide 2) October 28,

10 Live variables Dead code elimination Dead Code Elimination An assignment [x := a] l is dead if the value of x is not used before it is redefined. Dead assignments can be eliminated from the program. 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 Live variables 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 c HRN&FN (cf. slide 2) October 28,

11 Live variables Faint variables Faint variables Consider the following program: [x:=1] 1 ; [x:=x-1] 2 ; [x:=2] 3 Clearly x is dead at the exits from 2 and 3. But x is live at the exit of 1 even though its only use is to calculate a new value for a variable that turns out to be dead. We shall say that a variable is a faint variable if it is dead or if it is only used to calculate new values for faint variables; otherwise it is strongly live. In the example x is faint at the exits from 1 and 2. Exercise: Define a data flow analysis that detects strongly live variables. c HRN&FN (cf. slide 2) October 28,

12 Very busy expressions 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 ) c HRN&FN (cf. slide 2) October 28,

13 Very busy expressions The basic idea VB (l) [x := a] l VB (l) Analysis information: [...] l VB (l) [...] l 1 [...] l 2 VB (l 1 ) VB (l 2 ) VB (l): the expressions that are very busy at at the exit of block l VB (l): the expressions that are very busy at the entry of block l kill VB (l): the expressions that are killed by an elementary block gen VB (l): the expressions that are generated by an elementary block c HRN&FN (cf. slide 2) October 28,

14 Very busy expressions Analysis of elementary blocks Definition of the expressions that are killed by an elementary block (i.e. they values are no longer guaranteed to be needed in the future) and the assignments that are generated by the block (their values are now guaranteed to be needed in the future): 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) c HRN&FN (cf. slide 2) October 28,

15 Very busy expressions Analysis of programs VB (l) [x := a] l VB (l) [...] l VB (l) [...] l 1 [...] l 2 VB (l 1 ) VB (l 2 ) VB (l) = if l final(s ) {VB (l ) (l, l) flow R (S )} otherwise VB (l) = (VB (l)\kill VB (B l )) gen VB (B l ) where B l blocks(s ) c HRN&FN (cf. slide 2) October 28,

16 Very busy expressions Example if [a>b] 1 then ([x:=b-a] 2 ; [y:=a-b] 3 ) else ([y:=b-a] 4 ; [x:=a-b] 5 ) Equations: VB (1) = VB (1) VB (2) = VB (2) {b-a} VB (3) = {a-b} VB (4) = VB (4) {b-a} VB (5) = {a-b} VB (1) = VB (2) VB (4) VB (2) = VB (3) VB (3) = VB (4) = VB (5) VB (5) = Analysis of elementary blocks: l kill VB (l) gen VB (l) 1 2 {b-a} 3 {a-b} 4 {b-a} 5 {a-b} Largest solution: l VB (l) VB (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} c HRN&FN (cf. slide 2) October 28,

17 Very busy expressions Why largest solution? while [x>1] l do [skip] l od; [x:=x+1] l Equations: VB (l) = VB (l) VB (l ) = VB (l ) VB (l ) = {x+1} VB (l) = VB (l ) VB (l ) VB (l ) = VB (l) [x>1] l yes [skip] l no [x:=x+1] l VB (l ) = After some simplifications: VB (l) = VB (l) {x+1} Two solutions to this equation: {x+1} and c HRN&FN (cf. slide 2) October 28,

18 Very busy expressions Code hoisting Code Hoisting Code hoisting finds expressions that are always evaluated following some point in the program regardless of the execution path and moves them to the latest point beyond which they would always be executed. Example: if [a>b] 1 then ([x:= b-a ] 2 ; [y:= a-b ] 3 ) else ([y:= b-a ] 4 ; [x:= a-b ] 5 ) The Very Busy Expressions analysis enables a transformation into [t1:= b-a ] 6 ; [t2:= b-a ] 7 ; if [a>b] 1 then ([x:=t1] 2 ; [y:=t2] 3 ) else ([y:=t1] 4 ; [x:=t2] 5 ) c HRN&FN (cf. slide 2) October 28,

19 Bit vector frameworks The classical analyses revisited The classical analyses compute information in a set of the form P(D) for some finite set D and the equations have the general form: ι if l E A (l) = {A (l ) (l, l) F } otherwise A (l) = (A (l) \ kill l ) gen l where A, A : Lab P(D) and F is flow(s ) or flow R (S ) and E is {init(s )} or final(s ), is or on P(D) and ι D specifies the initial/final information, kill l D and gen l D specify the information invalidated by/generated by B l blocks(s ). c HRN&FN (cf. slide 2) October 28,

20 Bit vector frameworks Examples Available Reaching Very Busy Live Expressions Definitions Expressions Variables P(D) P(AExp ) P(Var Lab ) P(AExp ) P(Var ) ι {(x,?) x FV(S )} Var E {init(s )} {init(s )} final(s ) final(s ) F flow(s ) flow(s ) flow R (S ) flow R (S ) f l f l (X) = (X \ kill l ) gen l where B l blocks(s ) (and X D) c HRN&FN (cf. slide 2) October 28,

21 Bit vector frameworks Forward versus backwards analyses The forward analyses have F to be flow(s ) and then A concerns entry conditions and A concerns exit conditions. Reaching definitions analysis Available expressions analysis The backward analyses have F to be flow R (S ) and then A concerns exit conditions and A concerns entry conditions. Very busy expressions analysis Live variables analysis c HRN&FN (cf. slide 2) October 28,

22 Bit vector frameworks May versus must analyses 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 a may-analysis. Reaching definitions analysis Live variables analysis 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 a must-analysis. Available expressions analysis Very busy expressions analysis c HRN&FN (cf. slide 2) October 28,

23 Bit vector frameworks Bit vectors The classical analyses operate operates over elements of P(D) where D is a finite set. The elements can be represented as bit vectors: Each element of D can be assigned a unique bit position i (1 i n). A subset S of D is then represented by a vector of n bits: if the i th element of D is in S then the i th bit is 1 if the i th element of D is not in S then the i th bit is 0 Then we have efficient implementations of set union as logical or set intersection as logical and c HRN&FN (cf. slide 2) October 28,

24 Bit vector frameworks More bit vector frameworks Upwards exposed uses determines for a program point, what uses of a variable are reached by a particular definition (assignment) a backwards may analysis Copy analysis determines whether there on every execution path from a copy statement x := y to a use of x there are no assignments to y a forward must analysis Dominators determines for each program point which program points are guaranteed to have been executed before the current one is reached a forward must analysis Dual available expressions determines for each program point which expressions may not be available when execution reaches that point a forward may analysis c HRN&FN (cf. slide 2) October 28,

25 Bit vector frameworks Non-bit vector frameworks Constant propagation determines for each program point whether or not a variable has a constant value whenever execution reaches that point Detection of signs analysis determines for each program point the possible signs of that the values of the variables may have whenever execution reaches that point Faint variables determines for each program point which variables are faint: a variable is faint if it is dead or it it is only used to compute new values of faint variables May be unitialised determines for each program point which variables have dubious values: a variable has a dubious value if either it is not initialised or its value depend on variables with dubious values c HRN&FN (cf. slide 2) October 28,