SPARSE ABSTRACT INTERPRETATION!

Transcription

1 PROGRAMMING LANGUAGES LABORATORY! Universidade Federal de Minas Gerais - Department of Computer Science SPARSE ABSTRACT INTERPRETATION! PROGRAM ANALYSIS AND OPTIMIZATION DCC888! Fernando Magno Quintão Pereira! fernando@dcc.ufmg.br The material in these slides have been taken from the paper "Parameterized ConstrucAon of Program RepresentaAons for Sparse Dataflow Analyses", by Tavares et al. which is available in the course webpage.

2 Constant PropagaAon Revisited x = input a = 1 c = a + 10 What is the soluaon that our constant propagaaon analysis produces for this program? a < c b = x * a output b a = a + 1

3 Constant PropagaAon Revisited x = input a = 1 c = a + 10 a < c {x!nac, a!undef, b!undef, c!undef} {x!nac, a!1, b!undef, c!undef} {x!nac, a!1, b!undef, c!11} 1) How much space does this soluaon requires? Answer in terms of I, the number of instrucaons, and V, the set of variables. {x!nac, a!nac, b!nac, c!11} b = x * a output b a = a + 1 {x!nac, a!nac, b!undef, c!11} {x!nac, a!nac, b!nac, c!11} {x!nac, a!nac, b!nac, c!11} 2) Is there any redundancy in the soluaon given in the code on the les? 3) Why can't we simply bind the informaaon directly to the variable name, i.e., the variable is constant or not?

4 Binding InformaAon to Variables x = input a = 1 c = a + 10 a < c b = x * a output b a = a + 1 AssociaAng the informaaon with a variable name does not work in constant propagaaon, because the same variable name may denote a variable that is constant at some program points, and nonconstant at others. How could we solve this problem, so that the abstract state of a variable, i.e., constant or not, be invariant along this variable's enare live range?

5 Constant PropagaAon in SSA Form Programs x 0 = input a 0 = 1 c 0 = a a 1 =!(a 0, a 2 ) a 1 < c 0 b 0 = x 0 * a 1 output b 0 If we convert the program to StaAc Single Assignment form, then we can guarantee that the informaaon associated with a variable name is invariant along the enare live range of this variable. Why can we provide this guarantee about constant propagaaon, if the program is in StaAc Single Assignment form? a 2 = a 1 + 1

6 Sparse Constant PropagaAon x 0 = input a 0 = 1 c 0 = a a 1 = ϕ(a 0, a 2 ) a 1 < c 0 b 0 = x 0 * a 1 output b 0 a 2 = a [x 0 ] = NAC [a 0 ] = 1 [c 0 ] = 11 [a 1 ] = NAC [b 0 ] = NAC [a 2 ] = NAC The only instrucaon that determines if a variable is constant or not is the assignment. We have split live ranges at every point where new informaaon is acquired. Thus, we can bind the informaaon, i.e., the abstract state of a variable, to its live range. Whenever this is possible, we call the analysis sparse.

7 Dense vs Sparse x = input x 0 = input [x 0 ] = NAC a = 1 {x!nac, a!undef, b!undef, c!undef} a 0 = 1 [a 0 ] = 1 c = a + 10 {x!nac, a!1, b!undef, c!undef} c 0 = a [c 0 ] = 11 a < c {x!nac, a!1, b!undef, c!11} a 1 = ϕ(a 0, a 2 ) a 1 < c 0 [a 1 ] = NAC {x!nac, a!nac, b!undef, c!11} {x!nac, a!nac, b!nac, c!11} b = x * a output b {x!nac, a!nac, b!nac, c!11} b 0 = x 0 * a 1 output b 0 [b 0 ] = NAC a = a + 1 {x!nac, a!nac, b!nac, c!11} a 2 = a [a 2 ] = NAC Dense Which other analyses can we solve sparsely with SSA form? Sparse

8 Sparse Analyses If a data-flow analysis binds informaaon to pairs of program points variable names, then we call it dense. If the data-flow analysis binds informaaon to variables, then we call it sparse. But there is one more requirement for a data-flow analysis to be sparse: it must not use trivial transfer func0ons. We say that a transfer funcaon is trivial if it does not generate new informaaon. In other words, the transfer funcaon is an idenaty.

9 Trivial Transfer FuncAons The transfer funcaon associated with the assignment "a = 1" is non-trivial, because it changes the abstract state of the variable name "a". On the other hand, the transfer funcaon associated with the instrucaon "output b" is trivial, as it does not change the abstract state of any variable. a = 1 {x!nac, a!undef, b!undef, c!undef} {x!nac, a!1, b!undef, c!undef} output b {x!nac, a!nac, b!nac, c!11} {x!nac, a!nac, b!nac, c!11} A trivial transfer funcaon f is an idenaty, i = f(i). In other words, it receives some data-flow informaaon i, and outputs the same informaaon.

10 Building Sparse Data-Flow Analyses We want to build program representaaons that "sparsify" data-flow analyses. We will do it via live range spli7ng. We split the live range of a variable via copy instrucaons. a = 1 c < a a = 1 a 0 = a c < a 0!"#$!"#!$%&!#'(")*+!',"*$- $%&!'.,+./0!',"*$!1%&.&!1& %/2&!"*#&.$&3!/!*&1!4,'5!,6 2/."/7(&!/ 8 9!$%:#!#'(")*+!"$# ("2&!./*+&; <&!%/2&!.&*/0&3!%&%'()*$%!,6!2/."/7(&!/9!$%/$!"#!3,0"*/$&3!75!$%&!#'(")*+!',"*$9!$,!/ 8 ;

11 Spli[ng Points We split live ranges at the places where new informaaon is generated. In the case of constant propagaaon, we split at the definiaon point of variables. We split live ranges at the places where different informaaon may collide. In the case of constant propagaaon, we split at the join points of programs. L 1 : c = 1 L 0 : if (?) L 3 : print c L 2 : c = read() These are the places where new information is defined. And this is the place where information collides. We have dataflow facts coming from L1 and L2.

12 Spli[ng All Over is not What we Want If we split live ranges at every program point, then, naturally the informaaon associated with every live range will be invariant. x = input a = 1 x 0 = input a 1 = 1 x 1 = x 0 However, this live range spli[ng strategy does not gives us a sparse analysis. Why? a 2 = a 1, x 2 = x 1 b = a + x b 2 = a 2 + x 2 b 3 = b 2, a 3 = a 2, x 3 = x 2 c = b * a c 3 = b 3 * a 3 c 4 = c 3, b 4 = b 3, a 4 = a 3, x 4 = x 3 output c output c 4

13 We do not want trivial transfer funcaons We do not have a sparse analysis because many of the transfer funcaons associated with the copies are trivial. x 0 = input a 1 = 1 b 2 = a 2 + x 2 x 1 = x 0 a 2 = a 1, x 2 = x 1 For$instance,$here$our$transfer$ func0on$will$copy$the$abstract$state$of$ variable$a 2 $into$variable$a 3.$Thus,$these$ two$variables$will$always$have$the$ same$abstract$state,$and$the$transfer$ func0on$that$we$have$for$assignments$ is$not$genera0ng$any$new$informa0on. b 3 = b 2, a 3 = a 2, x 3 = x 2 c 3 = b 3 * a 3 output c 4 c 4 = c 3, b 4 = b 3, a 4 = a 3, x 4 = x 3 But, in this case, where do we split live ranges?

14 The Single InformaAon Property The informaaon that a data-flow analysis computes is a set of points in a la[ce. A dense analysis maps pairs of (program points variables) to these points. We say that a data-flow analysis has the single informa0on property for a given program if we can assign a single element of the underlying la[ce to each variable, and this informaaon is invariant along the enare live range of the variable. x 0 = input [x 0 ] = NAC NAC a 0 = 1 [a 0 ] = 1...!2! c 0 = a 0-2 [c 0 ] = -1 UNDEF

15 Universidade Federal de Minas Gerais Department of Computer Science Programming Languages Laboratory EXAMPLES OF LIVE RANGE SPLITTING DCC 888

16 Class Inference Analysis Some languages, such as Python, JavaScript and Lua, store the methods and fields of objects in hash-tables. It is possible to speedup programs wricen in these languages by replacing these tables by virtual tables. A class inference engine tries to assign a virtual table to a variable v based on the ways that v is used. Consider the Python program on the right. Where is class inference informaaon acquired? def test(i): v = OX() if i % 2: tmp = i + 1 v.m1(tmp) else: v = OY() v.m2() print v.m3() l 3 : tmp = i + 1 l 4 : v.m 1 ( ) l 1 : v = OX( ) l 2 : (i%2)? l 7 : v.m 3 ( ) l 5 : v = OY( ) l 6 : v.m 2 ( ) : CustomizaAon: opamizing compiler technology for SELF, a dynamically-typed object-oriented programming language

17 Class Inference Analysis We discover informaaon based on the way an object is used. If the program calls a method m on an object o, then we assume that m is part of the class of o. l 1 : v = OX( ) l 2 : (i%2)? l 3 : tmp = i + 1 l 4 : v.m 1 ( ) l 7 : v.m 3 ( ) So, where should we split live ranges, to ensure the single informaaon property? l 5 : v = OY( ) l 6 : v.m 2 ( ) l 3 : tmp = i + 1 {m 1,m 3 } l 4 : v.m 1 ( ) l 1 : v = OX( ) l 2 : (i%2)? {m 1,m 3 } {m 1,m 3 } {} l 5 : v = OY( ) {m 2,m 3 } l 6 : v.m 2 ( ) {m 3 } {m 3 } l 7 : v.m 3 ( )

18 Backward PropagaAon You are probably wondering why informaaon propagates backwardly, and not forwardly, in this analysis, aser all, once I use a method, I know that the method is in the class aser the use. 1) Do we really know this in Python? 2) What about in Java? 3) What could be different in these two languages to jusafy the second quesaon?

19 Backward PropagaAon You are probably wondering why informaaon propagates backwardly, and not forwardly, in this analysis, aser all, once I use a method, I know that the method is in the class aser the use. class X:! def init (self):! self.x = 0;! def m(self):! print(self.x)! self.m = 0! >>> x = X() >>> x.m() 1 >>> x.m() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'int' object is not callable

20 The Points where We Acquire InformaAon l 1 : v = OX( ) {m 1,m 3 } l 2 : (i%2)? {m 1,m 3 } {} In the class inference analysis, informaaon propagates backwards: if a method m is invoked on an object o at a program point p, we know that o must have the method m everywhere before p. l 3 : tmp = i + 1 l 5 : v = OY( ) {m 1,m 3 } {m 2,m 3 } l 4 : v.m 1 ( ) l 6 : v.m 2 ( ) {m 3 } {m 3 } l 7 : v.m 3 ( ) 1) So, in the end, where is informaaon acquired? 2) And where is informaaon colliding? 3) How many variable names would we have in the transformed program?

21 Backward Live Range Spli[ng Given this IR, how can we solve class inference analysis? tmp = i + 1 v 1 = OX( ) (i%2)? (v 2, ") =! (v 1 ) v 3 = OY( ) We represent these backward merge points using these special instructions, that we call sigmafunctions, to distinguish them from the phi-functions used in the forward merge points. No information is arriving at the second parameter of the sigmafunction, thus we represent it as an undefined name, denoted by " (v 4 ) = (v 2 ) v 2.m 1 ( ) v 6 =! (v 4, v 5 ) v 6.m 3 ( ) (v 5 ) = (v 3 ) v 3.m 2 ( ) We use this notation of parallel copies, e.g.,, to indicate that there is some live range splitting happening at that program point. We shall talk more about this notation soon.

22 Class Inference as a Constraint System What do you noace about the right side of these equaaons? v 1 = OX( ) (i%2)? (v 2, v 7 ) =! (v 1 ) [v 2 ] " [v 7 ] # [v 1 ] {} # [v 7 ] {m 1 } $ [v 4 ] # [v 2 ] tmp = i + 1 v 3 = OY( ) {m 2 } $ [v 5 ] # [v 3 ] (v 4 ) = (v 2 ) v 2.m 1 ( ) (v 5 ) = (v 3 ) v 3.m 2 ( ) [v 6 ] # [v 5 ] [v 6 ] # [v 4 ] v 6 =! (v 4, v 5 ) v 6.m 3 ( ) {m 3 } # [v 6 ]

23 Is SSA Form Really Necessary? The representaaon that we have produced is in SSA form. It is very convenient to keep the program in this representaaon: Helps other analyses. Compiler already does it. Fast liveness check. Yet, we do not really need SSA form for this paracular backward analysis. tmp = i + 1 (v 4 ) = (v 2 ) v 2.m 1 ( ) If we only split live ranges where informaaon is produced, how would our IR be? v 1 = OX( ) (i%2)? (v 2, v 7 ) =! (v 1 ) v 6 =! (v 4, v 5 ) v 6.m 3 ( ) v 3 = OY( ) (v 5 ) = (v 3 ) v 3.m 2 ( ) : Fast Liveness Checking for SSA-Form Programs, CGO (2008)

24 A More Concise RepresentaAon v 1 = OX( ) (i%2)? (v 2, v 7 ) =! (v 1 ) The program on the right is no longer in SSA form. It has fewer variable names. How would be the constraint system for this new program representaaon? v 1 = OX( ) (i%2)? (v 2, v 7 ) =! (v 1 ) tmp = i + 1 v 3 = OY( ) tmp = i + 1 v 3 = OY( ) (v 4 ) = (v 2 ) v 2.m 1 ( ) (v 5 ) = (v 3 ) v 3.m 2 ( ) (v 6 ) = (v 2 ) v 2.m 1 ( ) (v 6 ) = (v 3 ) v 3.m 2 ( ) v 6 =! (v 4, v 5 ) v 6.m 3 ( ) v 6.m 3 ( )

25 A Constraint System for the Non-SSA form Program v 1 = OX( ) [v 2 ]! [v 7 ] " [v 1 ] (i%2)? (v 2, v 7 ) =! (v 1 ) {} " [v 7 ] {m 1 } # [v 6 ] " [v 2 ] tmp = i + 1 (v 6 ) = (v 2 ) v 2.m 1 ( ) v 6.m 3 ( ) v 3 = OY( ) (v 6 ) = (v 3 ) v 3.m 2 ( ) {m 2 } # [v 6 ] " [v 3 ] {m 3 } " [v 6 ] Which constraint system is simpler: this one, or that for the SSA-form program?

26 Tainted Flow Analysis The goal of the tainted flow analysis is to find out if there is a path from a source of malicious informaaon to a sensiave operaaon. 1) Does the program below contain a tainted flow vulnerability? 2) To which kind of acack? l 1 : v = input( ) l 2 : v = "Hi!" l 3 : echo v l 4 : echo v 3) Where is new informaaon acquired in this type of analysis? 4) How does this informaaon propagate along the CFG? l 7 : echo v l 5 : is v Clean? l 6 : echo v

27 InformaAon in the tainted flow analysis propagates forwardly. And we can learn new facts from condiaonal tests. CondiAonal Tests l 1 : v = input( ) l 3 : echo v l 2 : v = "Hi!" {v = tainted} {v = clean} l 4 : echo v So, where should we split live ranges, to ensure the single informaaon property? {v = tainted} {v = clean} l 5 : is v Clean? T F {v = clean} {v = tainted} l 7 : echo v l 6 : echo v

28 Spli[ng ASer CondiAonals v 1 = input( ) v 2 = "Hi!" echo v 1 echo v 2 And which constraints can we extract from this program representaaons? v 3 =! (v 1, v 2 ) is v 3 Clean? (v 4, v 5 ) =! (v 3 ) echo v 4 echo v 5 We use sigma-functions after conditional tests, to split live ranges. In fact, we use sigma-functions whenever we need to copy the contents of a variable to multiple locations.

29 Tainted Analysis as a Constraint System v 1 = input( ) v 2 = "Hi!" {Clean}! [v 2 ] echo v 1 echo v 2 {Tainted}! [v 1 ] v 3 =! (v 1, v 2 ) is v 3 Clean? (v 4, v 5 ) =! (v 3 ) [v 1 ] " [v 2 ]! [v 3 ] {Clean}! [v 5 ] {Tainted}! [v 4 ] echo v 4 echo v 5

30 Null Pointer Analysis Type safe languages, such as Java, prefix method calls with a test that checks if the object is null. In this way, we cannot have segmentaaon faults, but only well-defined excepaons. Exception in thread "main"! java.lang.nullpointerexception!! at Test.main(Test.java:7)! l 2 : v.m( ) l 3 : v.m( ) l 1 : v = foo( ) Consider the program on the right. Which calls can result in null pointer excepaons, and which calls are always safe? l 4 : v.m( )

31 Null Pointer Analysis 1) Can the call at l 4 result in a null pointer excepaon? 2) Where is informaaon produced? Java, being a programming language that is type safe, must ensure dynamically that every call to an object that is null fires an excepaon. 3) How is a null pointer check implemented? 4) What do we gain by eliminaang these tests? 5) Can you split the live ranges of this program? v = maybe v = not null l 2 : v.m( ) l 3 : v.m( ) v = not null l 1 : v = foo( ) l 4 : v.m( ) v = maybe

32 Spli[ng ASer Uses In the case of null check eliminaaon, we split live ranges aser uses. If we invoke a method m on an object o, and no excepaon happens, then we know that m can be safely invoked on o in any program point aser the use point. As an example, an excepaon can never happen at this point, because otherwise it would have happened at the previous use of v 1, e.g., v 1.m() How can we transform this problem in a constraint system? v 1.m( ) v 2 = v 1 v 2.m( ) v 3 = v 2 v 1 = foo( ) v 4 =! (v 3, v 1 ) v 4.m( )

33 Null Pointer Check EliminaAon as Constraints Can you think about other analyses that would use the same live range spli[ng strategy as null pointer check eliminaaon? v 1 = foo( ) {Maybe}! [v 1 ] {Not Null}! [v 2 ] v 1.m( ) v 2 = v 1 {Not Null}! [v 3 ] v 2.m( ) v 3 = v 2 [v 3 ] " [v 1 ]! [v 4 ] v 4 =! (v 3, v 1 ) v 4.m( )

34 Universidade Federal de Minas Gerais Department of Computer Science Programming Languages Laboratory LIVE RANGE SPLITTING STRATEGIES DCC 888

35 Live Range Spli[ng NotaAon We use three special notaaons to indicate that we are spli[ng live ranges. Phi-funcAons split at join points. Sigma-funcAons split at branch points. Parallel copies split at interior points. v 1 = OX( ) (i%2)? (v 2, v 7 ) =! (v 1 ) tmp = i + 1 v 3 = OY( ) (v 4 ) = (v 2 ) v 2.m 1 ( ) (v 5 ) = (v 3 ) v 3.m 2 ( ) v 6 =! (v 4, v 5 ) v 6.m 3 ( )

36 Parallel Copies We split live ranges at interior nodes via parallel copies. Usually there is no assembly equivalent of a parallel copy; nevertheless, we can implement them with move or swap instrucaons. SemanAcally, we have a program point p like: (a 1 = a 0 ) (b 1 = b 0 ) x 1 = f(y 0, z 0 ), we read all the variables used at p, e.g., a 0, b 0, y 0, z 0, then write all the variables defined at p, e.g., a 1, b 1, x 1. All the reads happen in parallel. All the writes happen in parallel.

37 Phi-FuncAons Phi-funcAons work as mulaplexers: they choose a copy based on the program flow. We may have mulaple phi-funcaons at the beginning of a basic-block. If we have N phi-funcaons with M arguments at a basic block, then we have M parallel copies of N variables. L 0 : a 0 =! L 1 : b 0 =! c 0 =! L 2 : a 2 =! (a 0, a 1 ) b 2 =! (b 0, b 1 ) c 2 =! (c 0, c 1 )... a 1 =! b 1 =! c 1 =! In this example, if control reaches L 2 from L 0, then we have the parallel copy (a 2 = a 0 ) (b 2 = b 0 ) (c 2 = c 0 ); otherwise we have the parallel copy (a 2 = a 1 ) (b 2 = b 1 ) (c 2 = c 1 )

38 Sigma-FuncAons Sigma-FuncAons work as demulaplexers: they choose a parallel copy based on the path taken at a branch. In this example, if we branch from L 0 to L 1, then the following parallel copy takes place: (a 1 = a 0 ) (b 1 = b 0 ) (c 1 = c 0 ); otherwise we have the parallel copy (a 2 = a 0 ) (b 2 = b 0 ) (c 2 = c 0 ) L 0 :... a 0 =! b 0 =! c 0 =!... (a 1, a 2 ) =! a 0 (b 1, b 2 ) =! b 0 (c 1, c 2 ) =! c 0 L 1 :! = a 1! = b 1! = c 1... L 2 :! = a 2! = b 2! = c 2...

39 Live Range Spli[ng Strategy A live range spli[ng strategy for variable v, is a set P v = I I of "oriented" program points. The set I denotes points that produce informaaon that propagates forwardly. The set I denotes points that produce informaaon that propagates backwardly. Live ranges must be split at least in every point of P v. And each split point may cause further spli[ng, as we will see soon. We have seen this kind of cascading behavior, when converang a program to SSA form. Do you remember the exact situaaon?

40 l 1 : v = OX( ) Quiz Time: Class Inference l 2 : (i%2)? l 3 : tmp = i + 1 l 5 : v = OY( ) l 4 : v.m 1 ( ) l 6 : v.m 2 ( ) l 7 : v.m 3 ( ) What is the live range spli[ng strategy for the class inference analysis of our original example?

41 Quiz Time: Class Inference l 1 : v = OX( ) l 2 : (i%2)? l 3 : tmp = i + 1 l 5 : v = OY( ) Class inference acquires informaaon from uses, and propagates it backwardly. This gives us the following live range spli[ng strategy: P v = {l 4, l 6, l 7 } l 4 : v.m 1 ( ) l 6 : v.m 2 ( ) l 7 : v.m 3 ( )

42 Quiz Time: Null Pointer Check EliminaAon l 1 : v = foo( ) What is the live range spli[ng strategy for our "null pointer check eliminaaon" analysis? l 2 : v.m( ) l 3 : v.m( ) l 4 : v.m( )

43 Quiz Time: Null Pointer Check EliminaAon l 2 : v.m( ) l 1 : v = foo( ) Null pointer check eliminaaon takes informaaon from the uses, and from the definiaon of variables, and propagates it forwardly. This gives us the following live range spli[ng strategy: P v = {l 1, l 2, l 3, l 4 } l 3 : v.m( ) l 4 : v.m( )

44 Quiz Time: Tainted Flow Analysis l 1 : v = input( ) l 2 : v = "Hi!" l 3 : echo v l 4 : echo v l 5 : is v Clean? l 7 : echo v l 6 : echo v What is the live range spli[ng strategy for our tainted flow analysis, considering our example?

45 Quiz Time: Tainted Flow Analysis l 1 : v = input( ) l 2 : v = "Hi!" l 3 : echo v l 4 : echo v l 5 : is v Clean? Tainted flow analysis takes informaaon from definiaons and condiaonal tests, and propagates this informaaon forwardly. This gives us the following live range spli[ng strategy: P v = {l 1, l 2, out(l 5 )}. We let out(l 5 ) denote the program point aser l 5. l 7 : echo v l 6 : echo v

46 Quiz Time: Constant PropagaAon l 1 : x = input l 2 : a = 1 Finally, what is the live range spli[ng strategy if we decide to do constant propagaaon in this example on the les? l 3 : c = a + 10 l 4 : a < c l 5 : b = x * a l 6 : output b l 7 : a = a + 1

47 Quiz Time: Constant PropagaAon l 1 : x = input l 2 : a = 1 l 3 : c = a + 10 l 4 : a < c l 5 : b = x * a l 6 : output b There are two main implementaaons of constant propagaaon. The simplest one just takes informaaon from definiaons. The more involved one uses also the result of equality tests to find out if a variable is constant or not. Assuming the simplest kind, we would have the following strategies: P x = {l 1 }, P a = {l 2, l 7 }, P c = {l 3 } and P b = {l 5 }. NoAce that we have to split live ranges for each different variable in our program. l 7 : a = a + 1 : Constant propagaaon with condiaonal branches, TOPLAS, 1991

48 Meet Nodes Consider a forward (resp. backward) data-flow problem where S(p, v) is the maximum fixed point soluaon for variable v and program point p. We say that a program point m is a meet node for variable v if, and only if, m has n predecessors (resp. successors), s 1,, s n, n > 2, and there exists i, j, 1 i < j n, such that S(s i, v) S(s j, v). l 3 : tmp = i + 1 l 4 : v.m 1 ( ) l 1 : v = OX( ) l 2 : (i%2)? l 7 : v.m 3 ( ) l 5 : v = OY( ) l 6 : v.m 2 ( ) NoAce that there is no cheap way to compute the meet nodes by just considering the structure of the program. Why?

49 CompuAng Meet Nodes In order to know the meet nodes, we must solve the analysis. But we need them to solve the analysis! So we will just approximate the set of meet nodes, using only structural properaes of the program's CFG: Dominance: a CFG node n dominates a node n' if every program path from the entry node of the CFG to n' goes across n. If n n', then we say that n strictly dominates n' Dominance fronber (DF): a node n' is in the dominance fronaer of a node n if n dominates a predecessor of n', but does not strictly dominate n'. Iterated dominance fronber (DF+): the iterated dominance fronaer of a node n is the fixed point of the sequence: DF 1 (n) = DF(n) DF i+1 (n) = DF i (n) {DF(z) z DF i (n)}

50 Iterated Dominance FronAer What is the DF+ of each node marked in red? a e f g h l i j k b c d a e f g h l i j k b c d a e f g h l i j k b c d a e f g h l i j k b c d

51 Iterated Dominance FronAer a e f g h l i j k b c d a e f g h l i j k b c d a e f g h l i j k b c d a e f g h l i j k b c d

52 Spli[ng at Meet Nodes If informaaon is produced at a point p, then we must recombine this informaaon at the iterated dominance fronaer of p. In this case, we are approximaang meet nodes as the nodes in the DF+(p). We split the live range of a variable v at meet nodes, for a forward analysis, in the same way we did it when building the StaAc Single Assignment form: If we have a node n with m predecessors, then we create a phi-funcaon at n, with m entries. How would we split if we had a definiaon of v at f? b c d f a e h l g i k j

53 Spli[ng at Meet Nodes If informaaon is produced at a point p, then we must recombine this informaaon at the iterated dominance fronaer of p. In this case, we are approximaang meet nodes as the nodes in the DF+(p). 1) When are all these copies really necessary? 2) How (and under which assumpaons) could we remove some of these copies? v =! v =! (v, v) v =! (v, v) v =! (v, v) v =! (v, v,v) v =! (v, v,v)

54 Pseudo-Defs and Pseudo-Uses at Extreme Nodes We can assume that we have a pseudo-definiaon of the variable, at the entry node of the Control Flow Graph. This pseudo-definiaon avoids the problem of paths in which a variable might not have been iniaalized. v =! But, in any case, we only need to split live ranges where these live ranges exist, i.e., where the variable is alive. v =! (v, v) Nevertheless, it is not wrong to insert phi-funcaons at places where the variable is not alive. We can simplify macers a licle bit assuming a pseudo use at the exit node of the CFG. v =! (v, v) v =! v =! (v, v) v =! (v, v, v) v =! (v, v, v)! = v

55 Backward Analyses For backward analyses we do everything "backwardly". Instead of the iterated dominance fronaer, we consider the iterated post-dominance fronaer. Post-Dominance: a CFG node n post-dominates a node n' if every program path from n' to the exit node of the CFG goes across n. If n n', then we say that n strictly post-dominates n' Post-Dominance fronber (DF): a node n' is in the post-dominance fronaer of a node n if n post-dominates a successor of n', but does not strictly post-dominate n'. Iterated post-dominance fronber (PDF+): the iterated post-dominance fronaer of a node n is the fixed point of the sequence: PDF 1 (n) = PDF(n) PDF i+1 (n) = PDF i (n) {PDF(z) z PDF i }

56 Dominators and Post-Dominators a m x What is the dominance and post-dominance relaaons between each node in these three graphs? b n y

57 Dominators and Post-Dominators a m x Node 'a' dominates node 'b', for any path from start to 'b' goes across 'a'. Similarly, node 'b' postdominates node 'a', for any (backwards) path from the end of the CFG to 'a' must go across 'b'. b n y Node n post-dominates node m, but m does not dominate n. Node x dominates node y, but y does not post-dominate node x.

58 a e f g h l i j k b c d a e f g h l i j k b c d a e f g h l i j k b c d a e f g h l i j k b c d Iterated Post-Dominance FronAer What is PDF+ of each node marked in red?

59 a e f g h l i j k b c d a e f g h l i j k b c d a e f g h l i j k b c d a e f g h l i j k b c d Iterated Post-Dominance FronAer

60 A Cheap Trick The post-dominance relaaons are equivalent to the dominance relaaons if we reverse the edges of the CFG. b a e i As an example, the post-dominance fronaer of h, in the CFG on the upper right is the same as the dominancefronaer of h in the CFG in the lower right. c d f h l a g k j b e i c f g j d h k l

61 Spli[ng for Backward Analyses If we produce informaaon for variable v at a program point p, then we must split the live range of v at every node that is in the post-dominance fronaer of v. We do this live range spli[ng via sigma-funcaons, which we insert at the nodes in PDF+(v). a How would we split live ranges if we had a definiaon of variable v at node k in the control flow graph on the right? b c d f e h g i k j! = v l

62 Spli[ng for Backward Analyses If we produce informaaon for variable v at a program point p, then we must split the live range of v at every node that is in the post-dominance fronaer of v. We do this live range spli[ng via sigma-funcaons, which we insert at the nodes in PDF+(v). If we have a node n with m successors, then we create a sigma-funcaon at n, defining m new versions of v. b c (v, v, v) =! v (v, v) =! v (v, v) =! v (v, v) =! v i j d (v, v) =! v " = v l

63 Renaming Variables Once we have split variables, we must rename them, ensuring that each variable is bound to a unique informaaon, which is invariant along its live range. v =! How would we rename variables in each program? v = " (v, v, v) =! v v =! (v, v) b (v, v) =! v i v =! c (v, v) =! v (v, v) =! v j v =! (v, v) v =! (v, v) v =! (v, v, v) d (v, v) =! v " = v v =! (v, v, v) l! = v " = v

64 Renaming Variables v 1 = " 1) Can you devise an algorithm to rename variables? v 7 = " (v 1, v 6, v 3 ) =! v 7 v 3 =! (v 2, v 1 ) b (v 5, v 4 ) =! v 6 i v 2 = " c (v 1, v 2 ) =! v 5 (v 2, v 3 ) =! v 4 j v 4 =! (v 1, v 2 ) v 3 =! (v 2, v 1 ) v 7 =! (v 3, v 1, v 1 ) d (v 6, v 1 ) =! v 2 " = v 3 v 5 =! (v 4, v 3,v 7 ) l " = v 6 2) Is this algorithm the same for forward and backward analyses? " = v 1

65 Forward analyses: Renaming Variables For each definiaon site v = at a program point p, in any order: Find a new name v i to v; Rename every use of v that is dominated by p to v i Backward analyses: For each use site = v where informaaon originates, at a program point p, in any order: Find a new name v i to v; Rename every use of v, and each definiaon of v, that is postdominated by p to v i 1) For the backward analysis we are considering only use sites. Why not to consider also definiaon sites?

66 Pruning Unused Copies Our live range spli[ng algorithm may insert copies that are not used (nor defined) in the program, if we do not consider the pseudo-definiaons and the pseudo-uses. We can remove some of these copies. This process is called pruning. x = 1) Consider the program on the right. How would we split live ranges for a forward analysis that extracts informaaon from definiaons and condiaonal tests? 2) Can you name an actual analysis that behaves like this? x > 0 x < 100 = x

67 Pruning Unused Copies 1) Many new versions of variable x are unnecessary. Can you name a few? 2) How could we simplify the program on the right? 3) What is the complexity of this simplificaaon algorithm? x = x 0 = x > 0 x < 100 x 0 > 0 (x 4, x 1 ) =! x 0 x 0 < 100 (x 2, x 5 ) =! x 0 x 3! = (x 1, x 2 ) = x = x 3

68 Pruning by Liveness We can prune by liveness: if a copy of the variable is not alive, i.e., there is no path from this copy to a use of the variable that does not go across a redefiniaon of it, then we can eliminate this copy. x 0 = We have to run the liveness analysis dataflow algorithm, or is there a simpler way to find if a variable is useful or not? x 0 = x 0 > 0 (x 4, x 1 ) =! x 0 x 0 < 100 (x 2, x 5 ) =! x 0 x 0 > 0 (", x 1 ) =! x 0 x 0 < 100 (x 2, ") =! x 0 x 3! = (x 1, x 2 ) x 3! = (x 1, x 2 ) = x 3 = x 3

69 BidirecAonal Analyses l 1 : a = y l 0 : a = x There exist data-flow analyses that propagate informaaon both forwardly, and backwardly. Consider, for instance, bitwidth analysis: we want to know the size, in bits, of each variable. 1) Why would we be willing to know the size, in bits, of each variable? 2) Which statements produce new informaaon in this analysis? l 2 : if a > 10 goto l 3 l 3 : print v[a] 3) How does each of these statements propagate informaaon? : Bitwidth analysis with applicaaon to silicon compilaaon, PLDI (2000)

70 BidirecAonal Analyses " l 1 : a = y " l 0 : a = x 1) Which informaaon can we infer from the backward constraints? 2) And which informaaon can we learn from the forward constraints? " l 2 : if a > 10 goto l 3 3) How would be the intermediate program representaaon that we create for this example?! l 3 : print v[a] Backward flow: we know that a < v.len here, or the program would be wrong! Forward flow: we know that a > 10 at this program point.

71 Which constraints can we derive from this new program representaaon? BidirecAonal Analyses l 1 : a 1 = y l 0 : a 0 = x (a 2, a 3 ) =! (a 0 ) l 1 : a = y l 0 : a = x a 4 =! (a 1, a 2 ) l 2 : if a 4 > 10 goto l 3 (!, a 5 ) =! (a 4 ) l 2 : if a > 10 goto l 3 l 3 : print v[a] l 3 : a 6 =! (a 5, a 3 ) print v[a 6 ]

72 BidirecAonal Analyses l 1 : a 1 = y l 0 : a 4 =ϕ (a 1, a 2 ) l 2 : if a 4 > 10 goto l 3 (, a 5 ) =σ (a 4 ) l 3 : a 0 = x (a 2, a 3 ) =σ (a 0 ) a 6 =ϕ (a 5, a 3 ) print v[a 6 ] Forward flow: [a 0 ] [x] [a 1 ] [y] [a 2 ] [a 0 ] [a 3 ] [a 0 ] [a 4 ] MAX([a 1 ], [a 2 ]) [a 5 ] MIN([a 4 ], 10) [a 6 ] MAX([a 3 ], [a 5 ]) 1) Can you explain each one of these constraints? 2) And how are the backward constraints like?

73 BidirecAonal Analyses l 1 : a 1 = y l 0 : a 4 =ϕ (a 1, a 2 ) l 2 : if a 4 > 10 goto l 3 (, a 5 ) =σ (a 4 ) l 3 : a 0 = x (a 2, a 3 ) =σ (a 0 ) a 6 =ϕ (a 5, a 3 ) print v[a 6 ] Forward flow: [a 0 ] [x] [a 1 ] [y] [a 2 ] [a 0 ] [a 3 ] [a 0 ] [a 4 ] MAX([a 1 ], [a 2 ]) [a 5 ] MIN([a 4 ], 10) [a 6 ] MAX([a 3 ], [a 5 ]) Backward flow: [a 6 ] < [v.len] [a 5 ] [a 6 ] [a 3 ] [a 6 ] [a 4 ] [a 5 ] [a 1 ] [a 4 ] [a 2 ] [a 4 ] [a 0 ] MIN([a 2 ], [a 3 ]) [x] [a 0 ] [y] [a 1 ] Can you provide a raaonale for the backward constraints?

74 ImplemenAng Parallel Copies Actual instrucaon sets, in general, will not provide parallel copies. We must implement them using more convenaonal instrucaons. We already know how to implement phi-funcaons: we can replace these instrucaons with copies. But, how do we implement sigma-funcaons, and parallel copies placed at interior nodes? L 0 : a 0 = read() 1 : b 0 = read() 2 : if a 0 > b 0 goto L 6 L 0 : a 0 = read() 1 : b 0 = read() 2 : if a 0 > b 0 goto L 6 L 3 : b 1 = a 0 4 : goto L 0 L 6 : goto L 7 L 3 : b 1 = a 0 4 : b 2 = b 1 5 : goto L 0 L 6 : b 2 = b 0 7 : goto L 7 b 2 =!(b 0, b 1 ) L 7 : ret b 2 b 2 =!(b 0, b 1 ) L 8 : ret b 2

75 Dealing with Sigma-FuncAons We can represent sigma-funcaons as single-arity phifuncaons, at the beginning of basic blocks. v 1 = OX( ) (i%2)? (v 2, v 7 ) =! (v 1 ) And how do we implement parallel copies, e.g., (a 2 = a 1 ) (b 2 = b 1 ) (c 2 = c 1 )? v 1 = OX( ) (i%2)? tmp = i + 1 v 3 = OY( ) v 2 =! (v 1 ) tmp = i + 1 v 7 =! (v 1 ) v 3 = OY( ) (v 4 ) = (v 2 ) v 2.m 1 ( ) (v 5 ) = (v 3 ) v 3.m 2 ( ) v 2.m 1 ( ) v 4 = v 2 v 3.m 2 ( ) v 5 = v 3 v 6 =! (v 4, v 5 ) v 6.m 3 ( ) v 6 =! (v 4, v 5 ) v 6.m 3 ( )

76 ImplemenAng Parallel Copies Parallel copies can be implemented as sequences of move instrucaons. But ensuring correctness is not exactly a trivial problem. (a 2 = a 1 ) (b 2 = b 1 ) (c 2 = c 1 ) Phi-Assignment: v 1... v m =! l 1,..., l n v 11,..., v 1n v m1,..., v mn Sigma-Assignment: l 1,..., l n a 2 = a 1 ; b 2 = b 1 ; c 2 = c 1 This same strategy, of implemenang parallel copies as sequences of move instrucaons, can also be used to implement the parallel copies embedded in phi-funcaons and in sigmafuncaons. v 11,..., v 1n v m1,..., v mn =" v 1... v m Parallel-Assignment: v 1 u 1... v m =... u m : TilAng at Windmills with Coq: Formal VerificaAon of a CompilaAon Algorithm for Parallel Moves, JAR, 2008

77 A Bit of History A well-known acempt to implement a framework for Sparse Analyses is due to Choi et al. There have been many program representaaons for Sparse Analyses, such as Ananian's SSI and Bodik's e-ssa. These slides use the representaaon of Tavares et al. These representaaons sall use the core ideas introduced by Cytron et al. to build the staac single assignment form. Cytron, R., Ferrante, J., Rosen, B., Wegman, M., and Zadeck, K., "An Efficient Method of CompuAng StaAc Single Assignment Form", POPL, p (1989) Tavares, Boissinot, Pereira, and Rastello. "Parameterized ConstrucAon of Program RepresentaAons for Sparse Dataflow Analyses", CC, (2014) Choi, J., Cytron, R., and Ferrante, J., "AutomaAc ConstrucAon of Sparse Data Flow EvaluaAon Graphs", POPL, p (1991) Ananian, S., "The StaAc Single InformaAon Form", MSc DissertaAon, Massachusecs InsAtute of Technology (1999) Bodik., R., Gupta, R., and Sarkar, V., "ABCD: eliminaang array bounds checks on demand", PLDI, p (2000)