Presentation is loading. Please wait.

Presentation is loading. Please wait.

Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 17: Research Roman Manevich Ben-Gurion University.

Similar presentations


Presentation on theme: "Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 17: Research Roman Manevich Ben-Gurion University."— Presentation transcript:

1 Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 17: Research Roman Manevich Ben-Gurion University

2 Syllabus Semantics Natural Semantics Structural semantics Axiomatic Verification Static Analysis Automating Hoare Logic Control Flow Graphs Equation Systems Collecting Semantics Abstract Interpretation fundamentals LatticesFixed-Points Chaotic Iteration Galois Connections Domain constructors Widening/ Narrowing Analysis Techniques Numerical Domains Alias analysis Shape Analysis Interprocedural Analysis CEGAR Crafting your own Soot From proofs to abstractions Systematically developing transformers 2

3 Previously Pointer analysis Shape analysis 3

4 Agenda Projects Synthesizing parallel graph programs 4

5 Dynamic Security Analysis of Web Applications ( ) Joint project with Aviv Ron from IBM labs@BGU Goal: discover security violations in web applications, e.g., banks Challenge: search space is too large Current solution: restrict number of times each point of manipulation is tried Idea: – Guide search via abstraction – let it differentiate interesting moves from non-interesting ones – Use Machine learning to automatically obtain abstraction Tree Automata HTML Pages

6 Possible M.Sc. topic Language abstractions and synthesis for Software Defined Networks (SDN) Cooperation with Cisco 6

7 77 Elixir: Synthesis of Efficient Parallel Graph Algorithms Roman Manevich 2 Joint work with: Dimitrios Prountzos 1 and Keshav Pingali 1 1. The University of Texas at Austin 2. Ben Gurion University of the Negev

8 88 Parallel Computing Landscape Ubiquitous parallelism From data-centers to cellphones Emerging Problem Domains Sparse Graph Algorithms

9 9 Key Programming Challenge: Correctness + Performance Best solution: Input + Platform Dependent Parallel Programming is hard! Research Question Solution: Synthesis Input: Implicitly parallel specification Automatic Synchronization Search to find best solution Easy to explore algorithm/implementation insights

10 10 Key Programming Challenge: Correctness + Performance Best solution: Input + Platform Dependent Parallel Programming is hard! Research Question Solution: Elixir Input: Implicitly parallel specification Automatic Synchronization Search to find best solution Easy to explore algorithm/implementation insights

11 11 Outline Programming Challenge Language Abstractions Synthesis Technique Experimental Evaluation

12 Problem Formulation – Compute shortest distance from source node S to every other node Many algorithms – Bellman-Ford (1957) – Dijkstra (1959) – Chaotic relaxation (Miranker 1969) – Delta-stepping (Meyer et al. 1998) Common structure – Each node has label dist with known shortest distance from S Key operation – relax-edge(u,v) Example: Single-Source Shortest-Path 12 2 5 1 7 A A B B C C D D E E F F G G S S 3 4 2 2 1 9 2 A A C C 3 if dist(A) + W AC < dist(C) dist(C) = dist(A) + W AC

13 Scheduling of relaxations: Use priority queue of nodes, ordered by label dist Iterate over nodes u in priority order On each step: relax all neighbors v of u – Apply relax-edge to all (u,v) Dijkstra’s Algorithm 13 2 5 1 7 A A B B C C D D E E F F G G S S 3 4 2 2 1 9 7 5 3 6

14 Chaotic Relaxation Scheduling of relaxations: Use unordered set of edges Iterate over edges (u,v) in any order On each step: – Apply relax-edge to edge (u,v) 14 2 5 1 7 A A B B C C D D E E F F G G S S 3 4 2 2 1 9 5 12 (S,A) (B,C) (C,D) (C,E)

15 15 Q = PQueue[Node] Q.enqueue(S) while Q ≠ ∅ { u = Q.pop foreach (u,v,w) { if d(u) + w < d(v) d(v) := d(u) + w Q.enqueue(v) } W = Set[Edge] W ∪ = (S,y) : y ∈ Nbrs(S) while W ≠ ∅ { (u,v) = W.get if d(u) + w < d(v) d(v) := d(u) + w foreach y ∈ Nbrs(v) W.add(v,y) } Expressivity Gap Graph Algorithm =Operators+Schedule Dijkstra-styleChaotic-Relaxation

16 16 What is the Schedule? Graph Algorithm =Operators+Schedule Order activity processing Identify new activities Static Dynamic : activity “TAO of parallelism” PLDI’11 Compile-time binding in “algorithm body” = Operator Delta

17 17 Static Identify new activities Operators Dynamic Algorithms as Schedules Graph Algorithm =+Schedule Order activity processing Dijkstra-style Chaotic-Relaxation Q = PQueue[Node] Q.enqueue(S) while Q ≠ ∅ { u = Q.pop foreach (u,v,w) { if d(u) + w < d(v) d(v) := d(u) + w Q.enqueue(v) } W = Set[Edge] W ∪ = (S,y) : y ∈ Nbrs(S) while W ≠ ∅ { (u,v) = W.get if d(u) + w < d(v) d(v) := d(u) + w foreach y ∈ Nbrs(v) W.add(v,y) }

18 18 Static Identify new activities Operators Dynamic The Elixir Approach Graph Algorithm =+Schedule Order activity processing Dijkstra-style Q = PQueue[Node] Q.enqueue(S) while Q ≠ ∅ { u = Q.pop foreach (u,v,w) { if d(u) + w < d(v) d(v) := d(u) + w Q.enqueue(v) } Elixir provides Programming Model separating Operators Static Schedule Dynamic Schedule Automatic inference of Operator Delta Incremental fixpoint computations Advantages Increased Productivity Refined view of schedule exposes more concurrency Operator Delta Declarative Spec

19 19 Identify new activities DynamicStatic Operators Generating Efficient Parallel Programs Graph Algorithm =+Schedule Order activity processing Challenges Synchronization Multiple Protocols: Order + spin, Speculation Multiple Implementations for High-Level Statements E.g. exploit Graph ADT API Multiple Orderings for High-Level Statements E.g. Different orders of evaluating operator guards High-Level Program + Efficient Parallel Program ? Subtle Interactions

20 20 Generating Efficient Parallel Programs Graph Algorithm Challenges Synchronization Multiple Protocols Order + spin, Speculation Multiple Implementations for High-Level Statements E.g. exploit Graph ADT API Multiple Orderings for High-Level Statements E.g. Different orders of evaluating operator guards High-Level Program Efficient Parallel Program Elixir: Synthesis via Automated Planning = Identify new activities DynamicStatic Operators=+Schedule Order activity processing +

21 21 Elixir Contributions Language Abstractions Incremental Computations via Operator Delta Inference Efficient Parallel Programs via Planning-based Synthesis

22 22 Outline Programming Challenge Elixir Methodology Language Abstractions Incremental Computations via Operator Delta Inference Efficient Parallel Programs via Planning-based Synthesis Experimental Evaluation

23 23 Elixir Specifications: SSSP Graph [ nodes(node : Node, dist : int) edges(src : Node, dst : Node, wt : int) ] relax = [ nodes(node a, dist ad) nodes(node b, dist bd) edges(src a, dst b, wt w) bd > ad + w ] ➔ [ bd = ad + w ] sssp = iterate relax ≫ Graph Type Operator Fixpoint Statement

24 24 Elixir Specifications: Operator Graph [ nodes(node : Node, dist : int) edges(src : Node, dst : Node, wt : int) ] relax = [ nodes(node a, dist ad) nodes(node b, dist bd) edges(src a, dst b, wt w) bd > ad + w ] ➔ [ bd = ad + w ] sssp = iterate relax ≫ Shape Update Guard b b a a w adbd ➔ b b a a w adad+w

25 25 Elixir Specifications: Schedule Graph [ nodes(node : Node, dist : int) edges(src : Node, dst : Node, wt : int) ] relax = [ nodes(node a, dist ad) nodes(node b, dist bd) edges(src a, dst b, wt w) bd > ad + w ] ➔ [ bd = ad + w ] sssp = iterate relax ≫ Static: group, unroll, fuse, split Dynamic: metric, approx metric, fifo, lifo

26 26 Unconstrained Schedule Graph [ nodes(node : Node, dist : int) edges(src : Node, dst : Node, wt : int) ] relax = [ nodes(node a, dist ad) nodes(node b, dist bd) edges(src a, dst b, wt w) bd > ad + w ] ➔ [ bd = ad + w ] sssp = iterate relax

27 27 Dijkstra-style Variant Graph [ nodes(node : Node, dist : int) edges(src : Node, dst : Node, wt : int) ] relax = [ nodes(node a, dist ad) nodes(node b, dist bd) edges(src a, dst b, wt w) bd > ad + w ] ➔ [ bd = ad + w ] … a b1b1 bnbn sssp = iterate relax ≫ metric ad ≫ group b Q = PQueue[Node] Q.enqueue(S) while Q ≠ ∅ { u = Q.pop foreach (u,v,w) if d(u) + w < d(v) d(v) := d(u) + w Q.enqueue(v) }

28 28 sssp = iterate relax ≫ approx metric ad ≫ group b ≫ unroll 1 Chaotic-Relaxation Variant Graph [ nodes(node : Node, dist : int) edges(src : Node, dst : Node, wt : int) ] relax = [ nodes(node a, dist ad) nodes(node b, dist bd) edges(src a, dst b, wt w) bd > ad + w ] ➔ [ bd = ad + w ] … … a b1b1 bnbn

29 29 Outline Programming Challenge Elixir Methodology Language Abstractions Incremental Computations via Operator Delta Inference Efficient Parallel Programs via Planning-based Synthesis Experimental Evaluation

30 Problem Statement Many graph programs have the form until no change do { redex := find redex in graph apply operator to redex } Naïve implementation: keep looking for places where operator can be applied to make a change – Problem: too slow Incremental implementation: after applying an operator, find smallest set of future active elements and schedule them (add to worklist) 30

31 31 Challenge: Inferring Operator Delta b b a a relax 1 ? ?

32 32 Delta Inference Example a a b b c c w1w1 w2w2 relax 1 relax 2 assume da + w 1 < db assume ¬(db + w 2 < dc) db’ = da + w 1 assert ¬(db’ + w 2 < dc) Query Program ➜ SMT Solver ➜ ✗

33 33 Influence Patterns a a b b c c a a b b c c a a b b a a b b c c a a b b a a b b c c

34 34 a a b b c c a a b b c c a a b b c c a a b b a a b b c c a a b b Influence Patterns

35 35 From Specification to High-Level Program relax = [ nodes(node a, dist ad) nodes(node b, dist bd) edges(src a, dst b, wt w) bd > ad + w ] ➔ [ bd = ad + w ] Operator Schedule Tactic sssp = iterate relax a a b b c c Delta + + ➜ for (a,b) : (nodes,nodes) do if edge(a,b) if a ≠ b if da + w1 < db dist(b) := da + w for (c,d) : (nodes,nodes) do if c = b if edge(c,d) if c ≠ d if d ≠ a if d ≠ b async relax(c,d) fi … od High-Level Program Operator Delta

36 36 Outline Programming Challenge Elixir Methodology Language Abstractions Incremental Computations via Operator Delta Inference Efficient Parallel Programs via Planning-based Synthesis Experimental Evaluation

37 37 From High-Level Programs to Efficient Parallel Programs Reordering (T R ) Implementation Selection (T IS ) Synchronization (T Sync ) Challenges: Identify new activities DynamicStatic Operators Graph Algorithm =+Schedule Order activity processing High-Level Program + Efficient Parallel Program ?

38 38 Example: Triangles for a : nodes do for b : nodes do for c : nodes do if edges(a,b) if edges(b,c) if edges(c,a) if a < b if b < c if a < c triangles++ fi … … … Iterators Graph Conditions Scalar Conditions

39 39 Example: Triangles for a : nodes do for b : nodes do for c : nodes do if edges(a,b) if edges(b,c) if edges(c,a) if a < b if b < c if a < c triangles++ fi … ≺≺ Iterators Graph Conditions Scalar Conditions

40 40 for a : nodes do for b : nodes do for c : nodes do if edges(a,b) if edges(b,c) if edges(c,a) if a < b if b < c if a < c triangles++ fi … ≺≺ Triangles: Reordering Iterators Graph Conditions Scalar Conditions

41 41 Iterators Graph Conditions Scalar Conditions for a : nodes do for b : nodes do for c : nodes do if edges(a,b) if edges(b,c) if edges(c,a) if a < b if b < c if a < c triangles++ fi … ≺≺ for a : nodes do for b : Succ(a) do for c : Succ(b) do if edges(c,a) if a < b if b < c if a < c triangles++ fi … Triangles: Implementation Selection for x : nodes do if edges(x,y) ⇩ for x : Succ(y) do Reordering + Implementation Selection Tile:

42 42 Implementing Synchronization for a : nodes do if status(a) = … if ∀ b : Nbrs(a) { … } status(a) := … map b : Nbrs(a) { … } … lock a lock b ∈ Nbrs(a) Novel speculation-based synchronization Requires data flow analysis to insert custom locks/unlocks Maximal Independent Set else unlock a fi ctx ∅ ctx a

43 43 Reordering (T R ) Implementation Selection (T IS ) Synchronization (T Sync ) Synthesis Challenge Challenges: Staged: Integrated Order T R, T IS, T Sync as separate phases Apply T R, T IS, T Sync simultaneously Phase Ordering Identify new activities DynamicStatic Operators Graph Algorithm =+Schedule Order activity processing High-Level Program + Efficient Parallel Program ?

44 44 STRIPS-style Automated Planning Fluents : Domain facts E.g. Hold(x), Clear(x), On(x,y), … State: Fluent Valuation Actions : a Stack(x,y) Pickup(x) PutDown(x) Unstack(x,y) A B C D Unstack(B,A) ⊙ Pickup(B) ⊙ Stack(B,D) ⊙ Pickup(A) ⊙ Stack(A,B) Find finite action sequence from Init state to Goal state A B C D ➜

45 45 Planning with Temporal Constraints Specify constraints on state sequences G p (always) pppp ……. InitGoal

46 46 Planning with Temporal Constraints Specify constraints on state sequences p ⊏ q (happens before) ¬p,¬qp,¬qp,q ……. InitGoal

47 47 Elixir Architecture

48 48 Planning Framework Architecture

49 49 Planning-based Synthesis for a : nodes do if status(a) = … if ∀ b : Nbrs(a) { … } status(a) := … map b : Nbrs(a) { … } else exit fi od begin commit

50 50 Planning-based Synthesis for… if 1 (a) if 2 (N(a)) upd map else exit fi else exitfi od begin commit

51 51 Planning-based Synthesis for… if 1 (a) if 2 (N(a)) upd mapelse exit fi else exit fi od begin commit U

52 52 Planning-based Synthesis for… if 1 (a) if 2 (N(a)) upd map Planner else exit fi else exit fi od begin commit U ∀ u ∈ U: Once u for… begin if 1 (a) if 2 (N(a)) upd map commit else exit fi else exit fi od for… begin if 2 (N(a)) if 1 (a) upd map commit else exit fi else exit fi od od begin if 2 (a,N(a)) if 1 (a) upd map commit else exit fi else exit fi for…

53 53 Planning-based Synthesis for… if 1 (a) if 2 (N(a)) upd map Planner else exit fi else exit fi od begin commit U ∀ u ∈ U: Once u for… begin if 1 (a) if 2 (N(a)) upd map commit else exit fi else exit fi od for… begin if 2 (N(a)) if 1 (a) upd map commit else exit fi else exit fi od od begin if 2 (a,N(a)) if 1 (a) upd map commit else exit fi else exit fi for… for… ⊏ od (if 1,fi)(if 2,fi) ✔ ✗ ✔

54 54 Planning-based Synthesis for… if 1 (a) if 2 (N(a)) upd map Planner else exit fi else exit fi od begin commit U for… begin if 1 (a) if 2 (N(a)) upd map commit else exit fi else exit fi od for… begin if 2 (N(a)) if 1 (a) upd map commit else exit fi else exit fi od for… ⊏ od for… begin if 2 (N(a)) upd if 1 (a) map commit else exit fi else exit fi od (if 1,fi)(if 2,fi) if 1 ⊏ upd ∀ u ∈ U: Once u ✔ ✔ ✗

55 55 Synchronization Synthesis for… if 1 (a) if 2 (N(a)) upd map Planner else exit fi else exit fi od begin commit U for… begin lock a ctx ∅ if 1 (a) lock N(a) ctx a if 2 (N(a)) upd map unlock a,N(a) commit else unlock a,N(a) exit fi else unlock a exit fi od for… ⊏ od (if 1,fi)(if 2,fi) if 1 ⊏ upd lock a ctx ∅ lock a ctx N(a) lock N(a) ctx a lock N(a) ctx ∅ … Locked[r] ⊏ rd[r] ⋁ wr[r] ∀ u ∈ U: Once u if 2 with N(a) ctx rs …

56 56 Outline Programming Challenge Elixir Methodology Language Abstractions Incremental Computations via Operator Delta Inference Efficient Parallel Programs via Planning-based Synthesis Experimental Evaluation

57 57 Methodology Implementation Space Platform: 40-core Intel Xeon, 128 GB Times: median of 5 runs Plans Tiles, Schedules, Synchronization Elixir scheduling tactics group, unroll, fuse, split Use Graphs, Worklists from Galois Library Compare against solutions from expert programmers

58 58 Triangles foreach count ≫ group b,c A: B: foreach count ≫ group a,c foreach count ≫ group a,b C:C: for x : OrdSucc(y) do for x : nodes do if edges(x,y) if y < x →

59 59 MIS

60 60 SSSP 24 core Intel Xeon @ 2 GHz USA Florida Road Network Group+unroll improve performance

61 61 Connected Components Preflow-Push Connected ComponentsPreflow-Push

62 62 Conclusions Graph Algorithm = Operators + Schedule Elixir System Language Abstractions for increased productivity Imperative Operators + Declarative schedule Delta Inference leads to efficient fixpoint computations Planning-based Synthesis leads to efficient parallel programs Competitive performance with handwritten implementations

63 Agenda Introduction to automated planning – STRIPS model – Temporal goals – Soft goals Using planning for programming languages – Transformation – Analysis – Synthesis Open problems 63

64 Planning in blocks world Initial state Goal state Game rules: -No two blocks can be on top of the same block -Block can’t be on top of two blocks -Exact location on table or on block doesn’t matter ? ? B YG YG B

65 Planning in blocks world Initial state on-table(Y), clear(Y), on-table(G), on(R, G), on(B, R), clear(B) Goal state on-table(G), clear(G), on-table(Y), clear(Y), clear(R), on(R, B), on-table(B) on(i,j), on-table(i), clear(i)

66 Planning in blocks world Initial state Goal state Actions defined with: Move-Block( i )-from-Block(j)-to-Table Move-Block( i )-from-Table-to-Block(j) Move-Block( i )-from-Block(j)-to-Block(k) ? ?

67 Planning in blocks world B

68 Initial state Goal state Planning in blocks world B B G G Y Y R R G G Y Y R R B B G G R R

69 G R B Y GBY R

70 70 STRIPS-style Automated Planning Fluents : Domain facts E.g. Hold(x), Clear(x), On(x,y), … Literals: positive/negative fluents State: A set of fluents (fluents not in the set are false) Actions : a pre and post are sets of literals a(s) = if positive-pre  s and negative-pre  s = {} then s’ = s \ delete(a)  add(a) Stack(x,y) Pickup(x) PutDown(x) Unstack(x,y) A B C D Unstack(B,A) ⊙ Pickup(B) ⊙ Stack(B,D) ⊙ Pickup(A) ⊙ Stack(A,B) Find finite action sequence from Init state to subset of Goal state A B C D ➜

71 71 Planning with Temporal Goals

72 Temporal Goals Temporal goals specify properties of entire state sequences Specified in Linear Temporal Logic (LTL) Bad news: – Not well-supported by most planners – Some subtle issues with semantics of LTL when applied to finite sequences Good news – Can sometimes be compiled back to regular planning problems 72

73 73 Example: Always Goal G p(p always happens) pppp ……. InitGoal

74 74 Example: Once Goal Once p(p occurs exactly once) ¬p p ……. InitGoal How can we compile Once p to planning problem with regular goals?

75 75 Example: Happens Before p ⊏ q(p happens before q) ¬p,¬qp,¬qp,q ……. InitGoal How can we compile p ⊏ q to planning problem with regular goals?

76 Soft Goals Planner should attempt to satisfy as many soft goals as possible Can be used as a way to define quality of plans Some planners also allow associating numeric costs with actions – Planner strives for minimum-cost plans 76

77 77 Synthesis via Planning in Elixir

78 78 Elixir Architecture

79 79 Planning Framework Architecture

80 80 Planning-based Synthesis for a : nodes do if status(a) = … if ∀ b : Nbrs(a) { … } status(a) := … map b : Nbrs(a) { … } else exit fi od begin commit

81 81 Planning-based Synthesis for… if 1 (a) if 2 (N(a)) upd map else exit fi else exitfi od begin commit

82 82 Planning-based Synthesis for… if 1 (a) if 2 (N(a)) upd mapelse exit fi else exit fi od begin commit U

83 83 Planning-based Synthesis for… if 1 (a) if 2 (N(a)) upd map Planner else exit fi else exit fi od begin commit U ∀ u ∈ U: Once u for… begin if 1 (a) if 2 (N(a)) upd map commit else exit fi else exit fi od for… begin if 2 (N(a)) if 1 (a) upd map commit else exit fi else exit fi od od begin if 2 (a,N(a)) if 1 (a) upd map commit else exit fi else exit fi for…

84 84 Planning-based Synthesis for… if 1 (a) if 2 (N(a)) upd map Planner else exit fi else exit fi od begin commit U ∀ u ∈ U: Once u for… begin if 1 (a) if 2 (N(a)) upd map commit else exit fi else exit fi od for… begin if 2 (N(a)) if 1 (a) upd map commit else exit fi else exit fi od od begin if 2 (a,N(a)) if 1 (a) upd map commit else exit fi else exit fi for… for… ⊏ od (if 1,fi)(if 2,fi) ✔ ✗ ✔

85 85 Planning-based Synthesis for… if 1 (a) if 2 (N(a)) upd map Planner else exit fi else exit fi od begin commit U for… begin if 1 (a) if 2 (N(a)) upd map commit else exit fi else exit fi od for… begin if 2 (N(a)) if 1 (a) upd map commit else exit fi else exit fi od for… ⊏ od for… begin if 2 (N(a)) upd if 1 (a) map commit else exit fi else exit fi od (if 1,fi)(if 2,fi) if 1 ⊏ upd ∀ u ∈ U: Once u ✔ ✔ ✗

86 86 Synchronization Synthesis for… if 1 (a) if 2 (N(a)) upd map Planner else exit fi else exit fi od begin commit U for… begin lock a ctx ∅ if 1 (a) lock N(a) ctx a if 2 (N(a)) upd map unlock a,N(a) commit else unlock a,N(a) exit fi else unlock a exit fi od for… ⊏ od (if 1,fi)(if 2,fi) if 1 ⊏ upd lock a ctx ∅ lock a ctx N(a) lock N(a) ctx a lock N(a) ctx ∅ … Locked[r] ⊏ rd[r] ⋁ wr[r] ∀ u ∈ U: Once u if 2 with N(a) ctx rs …

87 87 Utilizing Planning for Programming Languages Operations

88 88 Project(s) Challenge: how to encode a programming task in terms of planning Steps: 1.Come up with algorithm, write it down formally 2.Download any modern planning tool and learn to use it Learn to program in PDDL 3.Demonstrate encoding on a few programs

89 89 Encoding Reordering Input: a program P Goal: generate a planning problem whose outputs are programs made from statements of P but possibly in different orders x := 1; if y>5 x := x+1; y := y*8; fi z := x-1; if z>6 x := x+2; fi if z>6 if y>5 y := y*8; z := x-1; fi x := x+1; x := x+2; fi x := 1;

90 90 Encoding Reordering u1: x := 1; u2: if y>5 u3: x := x+1; u4: y := y*8; u5: fi u6: z := x-1; u7: if z>6 u8: x := x+2; u9: fi Step 1: name each unit

91 91 Encoding Reordering u1: x := 1; u2: if y>5 u3: x := x+1; u4: y := y*8; u5: fi u6: z := x-1; u7: if z>6 u8: x := x+2; u9: fi Step 1: name each unit Planning problem Permutations(P) = Fluents = ? Initial = ? Actions = ? Goal = ?

92 92 Encoding Reordering Step 1: name each unit Planning problem Permutations(P) = Fluents = {u1,…,u9} Initial = {} Actions = { <> print_ui | i=1…9} Temporal goals = {Once u1,…,Once u9} u1: x := 1; u2: if y>5 u3: x := x+1; u4: y := y*8; u5: fi u6: z := x-1; u7: if z>6 u8: x := x+2; u9: fi u5: fi u9: fi u1: x := 1; u2: if y>5 u3: x := x+1; u4: y := y*8; u6: z := x-1; u7: if z>6 u8: x := x+2; What is the problem here and how do we prevent it?

93 93 Encoding Reordering Step 1: name each unit Planning problem = Fluents = {u1,…,u9} Initial = {} Actions = { <> print_ui | i=1…9} Temporal goals = {Once u1,…,Once u9}  SyntacticConstraints u1: x := 1; u2: if y>5 u3: x := x+1; u4: y := y*8; u5: fi u6: z := x-1; u7: if z>6 u8: x := x+2; u9: fi u5: fi u9: fi u1: x := 1; u2: if y>5 u3: x := x+1; u4: y := y*8; u6: z := x-1; u7: if z>6 u8: x := x+2;

94 Syntactic Constraints We want the output program to be in the context-free grammar of the output language For example – Opening and closing of scopes if b j ⊏ fi j while b j ⊏ od j – Balanced parentheses (if b j,fi j )(if b k,fi k ) 94

95 95 Syntactic Constraints Example Step 1: name each unit Planning problem = Fluents = {u1,…,u9} Initial = {} Actions = { <> print_ui | i=1…9} Temporal goals = {Once u1,…,Once u9}  {u2 ⊏ u5, u7 ⊏ u9, (u2,u5)(u7,u9) } u1: x := 1; u2: if y>5 u3: x := x+1; u4: y := y*8; u5: fi u6: z := x-1; u7: if z>6 u8: x := x+2; u9: fi u5: fi u9: fi u1: x := 1; u2: if y>5 u3: x := x+1; u4: y := y*8; u6: z := x-1; u7: if z>6 u8: x := x+2;

96 Challenge 1: Encode CFG How can we efficiently encode arbitrary (or at least substantial classes of) context-free grammars? Input: – Program P – CFG G whose alphabet is units(P) Output: planning problem  =Syntax(P,G) such that plans(  ) = Permutations(P)  L(G) Your task: design an algorithm for Syntax(P,G) for efficient  (small) and demonstrate on a few input programs 96

97 97 Encoding Dependencies Input: a program P Goal: generate a planning problem whose outputs preserve dependencies of the input program

98 98 Dependencies Example 1 Input: a program P Goal: generate a planning problem whose outputs preserve dependencies of the input program u1: x := 1; u2: if y>5 u3: x := x+1; u4: y := y*8; u5: fi u6: z := x-1; u7: if z>6 u8: y := y+2; u9: fi u1: x := 1; u2: if y>5 u4: y := y*8; u3: x := x+1; u5: fi u7: if z>6 u8: y := y+2; u9: fi u6: z := x-1; u2: if y>5 u1: x := 1; u3: x := x+1; u4: y := y*8; u5: fi u7: if z>6 u8: y := y+2; u9: fi u6: z := x-1; What is the problem here and how do we prevent it?

99 99 Dependencies Example 2 Input: a program P Goal: generate a planning problem whose outputs preserve dependencies of the input program u1: if y>5 u2: if z>5 u3: x := x+1; u4: y := y*8; u5: fi u6: fi u2: if z>5 u1: if y>5 u3: x := x+1; u4: y := y*8; u6: fi u5: fi Is this transformation correct?

100 100 Encoding Dependencies Run (simple) static analysis to identify dependencies Add appropriate scope constraints – If unit u is in scope of statement (if b, fi) then add if b ⊏ u ⊏ fi – Same for while b … u… od – Unless immediately-nested conditions/loops without dependencies between their conditions

101 Challenge 2: Encode DFG How can we efficiently encode data and control dependencies? Input: – Program P – DPG(P) (dependencies graph) Output: planning problem  =Depends(P,G) such that plans(  ) = Permutations(P)  {P’ | P  DFG(P)} Your task: – Read paper on dependence graphs – Design an algorithm for Depends(P,G) for efficient  (small) and demonstrate on a few input programs 101

102 Recap How can we efficiently encode data and control dependencies? Input: – Program P – DPG(P) (dependencies graph) Output: planning problem  = Perms(P) + Syntax(P,G) + Depends(P,G) Then every plan  Plans(  ) represents a program that is equivalent to P 102

103 Lowering How can we translate from one language to another? Idea: define for each input-language construct possible translations to low-level language and try to optimize Input: – Program P – Tiles T – A tile is a template of the form t = P’ where t is a unit and P’ is a sequence of units Output:  = Tiles(P,T) such that plans in  represent programs using only tiles 103

104 104 Tiles example 1 Tiles represent optimization patterns z:=z+2 = z:=z+1; z;=z+1 How can we encode them? u1: x := x+1; u2: x := x+1; u1,u2: x := x+2;

105 105 Tiles example 1 Tiles represent optimization patterns z:=z+2 = z:=z+1; z:=z+1 How can we encode them? Instantiate macro actions: <> print_”z:=z+2” Requires composing actions for individual unit actions An instance of inverse-homomorphism in DFA u1: x := x+1; u2: x := x+1; u1,u2: x := x+2;

106 106 Tiles example 2: multi-tiles We sometimes need tiles for non-atomic statements – Conditions – Loops Need to account for scopes – if b1 && b2 … fifi – Add temporal “tandem” goals if x>0 if y>0 S fi fi if x>0 && y>0 S fifi

107 107 Encoding Dataflow We would like to infer dataflow for programs in order to enable conditioned optimizations Input: – Program P – Dataflow problem D=(2 Factoid, , , {}, F : 2 Factoid  2 Factoid ) Output: plans such that each state includes dataflow information

108 108 Dataflow Example 1 Constant propagation – For each unit u add fluents u{v 1 =k 1,…, v n =k n } for all tuples of variables v 1,…,v n in program and some tuples of constants k 1,…,k n In general for each unit u and dataflow element d, add u{d} – works when number of dataflow facts is finite For each atomic action unit simulate transfer function update corresponding planning action u1: x := 1; u2: y := x+8; u1: x := 1; {x=1,y=  } u2: y := x+8;{x=1,y=9} Assume dataflow elements={1,9,  }

109 109 Dataflow Example 2 Handle conditions by remembering dataflow state before conditions – For each “if b” unit and dataflow element d create “if b” On corresponding fi unit join current dataflow element and remembered element u1: x := 1; u2: if y>5 u3: x := x+1; u4: y := y*8; u5: fi u1: x := 1; {x=1,y=  } u2: if y>5 {x=1,y= , u2 with x=1} u3: x := x+1;{x=2,y= , u2 with x=1} u4: y := y*8;{x=2,y= , u2 with x=1} u5: fi{x= ,y=  } x=2  x=1=x= 

110 110 Challenge 3a: Encoding Dataflow Input: – Program P – Dataflow problem D=(2 Factoid, , , {}, F : 2 Factoid  2 Factoid ) – Assume Factoid is finite set – Assume kill-gen transfer functions Output: planning problem  =Flow(P,D) such that plans(  ) are plans augmented with dataflow facts Task: – Find an encoding scheme that is sub-exponential in number of dataflow elements – Handle loops via soft goals Simpler task: handle context-aware locking

111 111 Implementing Synchronization for a : nodes do if status(a) = … if ∀ b : Nbrs(a) { … } status(a) := … map b : Nbrs(a) { … } … lock a lock b ∈ Nbrs(a) Novel speculation-based synchronization Requires data flow analysis to insert custom locks/unlocks Maximal Independent Set else unlock a fi ctx ∅ ctx a

112 112 Challenge 3b: Encoding Execution Goals Input: – Program P – Temporal goal EG over executions of program Output: planning problem  =Execution(P,EG) such that plans(  ) represent programs whose executions satisfy EG Task: consider execution goals given by finite automata – Demonstrate at least for – Globally – Happens-before – Happens-once – Balanced parentheses

113 113 Challenge 4: Register Allocation Given a program P with liveness information LV, and register set r1,…,rk Encode a planning problem for outputting a program P’ where atomic statements use registers r1,…,rk and memory addresses M1,…,Mn with minimal n

114 114 Challenge 5: Combining Metrics Use a planner to encode several optimality metrics – Order-relative for conditions – Duration metrics

115 Good Luck!


Download ppt "Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 17: Research Roman Manevich Ben-Gurion University."

Similar presentations


Ads by Google