interprocedural analysis
play

Interprocedural Analysis The Problem: match entries with exits proc - PowerPoint PPT Presentation

Interprocedural Analysis The Problem: match entries with exits proc fib(val z, u; res v) The problem is 1 MVP: Meet over Valid Paths no [ z<3 ] 2 Making context explicit yes [ call


  1. Interprocedural Analysis The Problem: match entries with exits proc fib(val z, u; res v) • The problem � is 1 � � • MVP: “Meet” over Valid Paths � no [ z<3 ] 2 • Making context explicit yes � � � [ call fib(x,0,y) ] 9 [ v:=u+1 ] 3 [ call fib(z-1,u,v) ] 4 10 5 � • Context based on call-strings � � � [ call fib(z-2,v,v) ] 6 7 � • Context based on assumption sets � � end 8 (A restricted treatment; see the book for a more general treatment.) PPA Section 2.5 82 PPA Section 2.5 83 � F.Nielson & H.Riis Nielson & C.Hankin (May 2005) c � F.Nielson & H.Riis Nielson & C.Hankin (May 2005) c Flow graphs for procedure calls Preliminaries Syntax for procedures init ([ call p ( a, z )] � c � r ) = � c final ([ call p ( a, z )] � c Programs: P � = begin D � S � end � r ) = { � r } blocks ([ call p ( a, z )] � c { [ call p ( a, z )] � c D ::= D ; D | proc p ( val x ; res y ) is � n S end � x Declarations: � r ) = � r } labels ([ call p ( a, z )] � c S ::= · · · | [ call p ( a, z )] � c � r ) = { � c , � r } Statements: � r flow ([ call p ( a, z )] � c � r ) = { ( � c ; � n ) , ( � x ; � r ) } Example: proc p ( val x ; res y ) is � n S end � x is in D � if proc fib ( val z , u ; res v ) is 1 begin • ( � c ; � n ) is the flow corresponding to calling a procedure at � c and if [ z<3 ] 2 then [ v:=u+1 ] 3 entering the procedure body at � n , and 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 • ( � x ; � r ) is the flow corresponding to exiting a procedure body at � x 10 and returning to the call at � r . end PPA Section 2.5 84 c PPA Section 2.5 85 � F.Nielson & H.Riis Nielson & C.Hankin (May 2005) � F.Nielson & H.Riis Nielson & C.Hankin (May 2005) c

  2. Flow graphs for programs For the program P � = begin D � S � end : Flow graphs for procedure declarations = init ( S � ) init � final � = final ( S � ) For each procedure declaration proc p ( val x ; res y ) is � n S end � x of D � : � { blocks ( p ) | proc p ( val x ; res y ) is � n S end � x is in D � } blocks � = init ( p ) = � n ∪ blocks ( S � ) final ( p ) = { � x } � { labels ( p ) | proc p ( val x ; res y ) is � n S end � x is in D � } = labels � { is � n , end � x } ∪ blocks ( S ) blocks ( p ) = ∪ labels ( S � ) labels ( p ) = { � n , � x } ∪ labels ( S ) � { flow ( p ) | proc p ( val x ; res y ) is � n S end � x is in D � } flow � = flow ( p ) = { ( � n , init ( S )) } ∪ flow ( S ) ∪ { ( �, � x ) | � ∈ final ( S ) } ∪ flow ( S � ) { ( � c , � n , � x , � r ) | proc p ( val x ; res y ) is � n S end � x is in D � = interflow � and [ call p ( a, z )] � c � r is in S � } PPA Section 2.5 86 � F.Nielson & H.Riis Nielson & C.Hankin (May 2005) c PPA Section 2.5 87 c � F.Nielson & H.Riis Nielson & C.Hankin (May 2005) Example: A naive formulation proc fib ( val z , u ; res v ) is 1 begin Treat the three kinds of flow in the same way: 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 ) flow treat as end 8 ; ( � 1 , � 2 ) ( � 1 , � 2 ) [ call fib ( x , 0 , y )] 9 10 ( � c ; � n ) ( � c ,� n ) end ( � x ; � r ) ( � x ,� r ) We have Equation system: flow � = { (1 , 2) , (2 , 3) , (3 , 8) , A • ( � ) = f � ( A ◦ ( � )) (2 , 4) , (4; 1) , (8; 5) , (5 , 6) , (6; 1) , (8; 7) , (7 , 8) , � { A • ( � � ) | ( � � , � ) ∈ F or ( � � ,� ) ∈ F or ( � � ,� ) ∈ F } � ι � A ◦ ( � ) = (9; 1) , (8; 10) } E = { (9 , 1 , 8 , 10) , (4 , 1 , 8 , 5) , (6 , 1 , 8 , 7) } interflow � But there is no matching between entries and exits. and init � = 9 and final � = { 10 } . PPA Section 2.5 89 PPA Section 2.5 88 c � F.Nielson & H.Riis Nielson & C.Hankin (May 2005) c � F.Nielson & H.Riis Nielson & C.Hankin (May 2005)

  3. MVP: “Meet” over Valid Paths Valid Paths Complete Paths A valid path starts at the entry node init � of P � , all the procedure exits We need to match procedure entries and exits: match the procedure entries but some procedures might be entered but not yet exited: A complete path from � 1 to � 2 in P � has proper nesting of procedure entries and exits; and a procedure returns to the point where it was VP � − → VP init � ,� whenever � ∈ Lab � called: whenever � 1 = � 2 VP � 1 ,� 2 − → � 1 whenever � 1 = � 2 CP � 1 ,� 2 − → � 1 VP � 1 ,� 3 − → � 1 , VP � 2 ,� 3 whenever ( � 1 , � 2 ) ∈ flow � CP � 1 ,� 3 − → � 1 , CP � 2 ,� 3 whenever ( � 1 , � 2 ) ∈ flow � whenever P � contains [ call p ( a, z )] � c VP � c ,� − → � c , CP � n ,� x , VP � r ,� � r whenever P � contains [ call p ( a, z )] � c and proc p ( val x ; res y ) is � n S end � x CP � c ,� − → � c , CP � n ,� x , CP � r ,� � r and proc p ( val x ; res y ) is � n S end � x whenever P � contains [ call p ( a, z )] � c VP � c ,� − → � c , VP � n ,� � r and proc p ( val x ; res y ) is � n S end � x More generally: whenever ( � c , � n , � x , � r ) is an element of interflow � (or interflow R � for backward analyses); see the book. PPA Section 2.5 91 � F.Nielson & H.Riis Nielson & C.Hankin (May 2005) c PPA Section 2.5 90 � F.Nielson & H.Riis Nielson & C.Hankin (May 2005) c Making Context Explicit The MVP solution Starting point: an instance ( L, F , F, E , ι, f · ) of a Monotone Framework � � ( ι ) | � MVP ◦ ( � ) = { f � � ∈ vpath ◦ ( � ) } � � ( ι ) | � MVP • ( � ) = { f � � ∈ vpath • ( � ) } • the analysis is forwards, i.e. F = flow � and E = { init � } ; where • the complete lattice is a powerset, i.e. L = P ( D ); vpath ◦ ( � ) = { [ � 1 , · · · , � n − 1 ] | n ≥ 1 ∧ � n = � ∧ [ � 1 , · · · , � n ] is a valid path } vpath • ( � ) = { [ � 1 , · · · , � n ] | n ≥ 1 ∧ � n = � ∧ [ � 1 , · · · , � n ] is a valid path } • the transfer functions in F are completely additive; and The MVP solution may be undecidable for lattices satisfying the As- • each f � is given by f � ( Y ) = � { φ � ( d ) | d ∈ Y } where φ � : D → P ( D ). cending Chain Condition, just as was the case for the MOP solution. (A restricted treatment; see the book for a more general treatment.) PPA Section 2.5 92 � F.Nielson & H.Riis Nielson & C.Hankin (May 2005) c PPA Section 2.5 93 � F.Nielson & H.Riis Nielson & C.Hankin (May 2005) c

  4. An embellished monotone framework Example: • L � = P ( ∆ × D ); Detection of Signs Analysis as a Monotone Framework: • the transfer functions in F � are completely additive; and ( L sign , F sign , F, E, ι sign , f sign ) where Sign = { - , 0 , + } and · L sign = P ( Var � → Sign ) • each f � � is given by f � � ( Z ) = � { { δ } × φ � ( d ) | ( δ , d ) ∈ Z } . The transfer function f sign associated with the assignment [ x := a ] � is � Ignoring procedures, the data flow equations will take the form: f sign � { φ sign ( σ sign ) | σ sign ∈ Y } ( Y ) = f � A • ( � ) = � ( A ◦ ( � )) � � for all labels that do not label a procedure call where Y ⊆ Var � → Sign and � { A • ( � � ) | ( � � , � ) ∈ F or ( � � ; � ) ∈ F } � ι � � φ sign A ◦ ( � ) = ( σ sign ) = { σ sign [ x �→ s ] | s ∈ A sign [ ]( σ sign ) } [ a ] E � for all labels (including those that label procedure calls) PPA Section 2.5 95 PPA Section 2.5 94 � F.Nielson & H.Riis Nielson & C.Hankin (May 2005) c � F.Nielson & H.Riis Nielson & C.Hankin (May 2005) c Transfer functions for procedure declarations Example (cont.): Procedure declarations Detection of Signs Analysis as an embellished monotone framework proc p ( val x ; res y ) is � n S end � x L � sign = P ( ∆ × ( Var � → Sign ) ) have two transfer functions, one for entry and one for exit: The transfer function associated with [ x := a ] � will now be: f � n , f � x : P ( ∆ × D ) → P ( ∆ × D ) � ( Z ) = � f sign { { δ } × φ sign ( σ sign ) | ( δ , σ sign ) ∈ Z } For simplicity we take both to be the identity function (thus incorpo- � � rating procedure entry as part of procedure call, and procedure exit as part of procedure return). PPA Section 2.5 96 c � F.Nielson & H.Riis Nielson & C.Hankin (May 2005) PPA Section 2.5 97 � F.Nielson & H.Riis Nielson & C.Hankin (May 2005) c

Recommend


More recommend