Constraint Based Analysis

Transcription

1 Seminar Constraint Based Analysis Toni Suter Fall Term 2014 Supervised by Prof. Peter Sommerlad

2 Abstract Static program analysis is used in compilers and refactoring tools as a means to examine the structure of a program. The result of an analysis can help in optimizing the program and in finding bugs in the source code. Many analyses need some knowledge about the control flow of the program in order to do their job. However, some programming language features can make this difficult because their use leads to code that is very dynamic and therefore hard to analyse at compile time. This paper briefly explains these problems and then shows how Constraint Based Control Flow Analysis can be used as a tool that enables the analysis of such code. Finally, it walks through an example which illustrates the steps that are involved in this process. I

3 Contents 1 Introduction Types of static program analysis Intraprocedural analysis Interprocedural analysis Control flow analysis How to represent an analysis result Acceptability Constraint generation Constraint resolution Graph Formulation Conclusion 18 1

4 1 Introduction Constraint Based Analysis is a form of static program analysis that uses systems of set contraints to describe certain aspects of a program. It can be used for many different kinds of analyses (e.g. to perform typechecking in a statically typed programming language or to analyse the control flow in a dynamic programming language where functions are first-class objects). This paper gives an overview over the various kinds of static program analyses and explores control flow analysis with the use of constraints in more detail. 1.1 Types of static program analysis Static program analysis is often used in compilers to perform optimizations such as constant folding and common subexpression elimination [ALSU06]. It can also be used to support stand-alone analysis and refactoring tools that help in finding bugs and improving the software quality. The subsections and describe the two main types of static program analysis: intraprocedural analysis and interprocedural analysis Intraprocedural analysis In intraprocedural analysis, the analyser examines individual procedures in isolation without the context of the entire program. As mentioned above, static program analysis is often used in compilers to optimize a program. Such an optimization consists of an analysis and a transformation. The analysis examines the program to determine whether it is possible and worthwhile to do the transformation. The transformation makes the actual changes that should lead to a better (e.g, faster, smaller, more energy-efficient, etc.) program. Many optimizations are based on intraprocedural analyses [CT11]. 2

5 1 Introduction For example, Common Subexpression Elimination (CSE) is an optimization that is based on an intraprocedural data flow analysis called Available Expression Analysis. Consider the pseudo-code in Listing 1.1: Listing 1.1: Before optimization 1 a := (c + d) * 2 2 b := (c + d) * 5 The Available Expression Analysis determines for each point p in the procedure, the expressions that are available. An expression is considered available if: 1. the expression is evaluated on every path to the point p 2. and the expression is not invalidated (killed) after the evaluation but before the point p (e.g, by assigning a new value to a variable that is used in the expression) Therefore, the expression (c + d) is considered available on line 2 and the result of the expression can be reused. This is shown in Listing 1.2: Listing 1.2: After optimization 1 tmp := c + d 2 a := tmp * 2 3 b := tmp * 5 This optimization improves the speed of the program by storing the result of the expression (c + d) in a temporary variable thereby removing the need to calculate the result twice. Live Variable Analysis, Reaching Definitions Analysis and Very Busy Expressions Analysis are other examples of intraprocedural analyses [NNH99]. All of these techniques depend on the fact that it is relatively easy to determine the control flow within a procedure. For example, if the control flow reaches the condition of an if-else statement, there are exactly 2 positions where it can continue; either in the if-block or the else-block. Since intraprocedural analysis doesn t analyse the interactions between different functions, the control flow is more or less predictable at compile time Interprocedural analysis Some intraprocedural optimizations may be used on a whole-program level. For example, Dead Code Elimination is an optimization technique that removes code which is never executed. If the analyser starts 3

6 1 Introduction analysing the control flow between functions (inter-flow), it may be able to apply this optimization across function calls. Consider the C++ code in Listing 1.3: Listing 1.3: Example for possible Dead Code Elimination 1 void f(int x) { 2 if(x < 0) { 3 //do something 4 } 5 else { 6 //do something else 7 } 8 } 9 10 int main() { 11 f(10); 12 f(5); 13 } In this example, an optimizing compiler may be able to use interprocedural data flow analysis to find out that the parameter x in the function f only ever takes on positive values in this program and that it s therefore possible to eliminate the if-branch from the code. However, calculating the interprocedural control flow of a program is often not a straightforward task. For example, at the end of a procedure there could be many different places where the control flow continues because procedures are usually called from various locations. Additionally, modern programming languages often support a form of dynamic dispatch which means that it is sometimes not possible to determine at compile time which function body is executed as a result of a function application. The following two subsections describe these problems in more detail. 4

7 1 Introduction Higher-order functions in JavaScript In JavaScript, functions are first-class objects which means that they can be stored in variables, passed as an argument or returned from another function [AS96]. Higher-order functions take one or more functions as an input or return a function [Lip11]. Listing 1.4 shows a higher-order function in JavaScript: Listing 1.4: Higher-order function in JavaScript 1 //filters an array based on a custom predicate 2 function filter(arr, predicate) { 3 var filtered = []; 4 5 for(var i = 0; i < arr.length; ++i) 6 if(predicate(arr[i])) 7 filtered.push(arr[i]); 8 9 return filtered; 10 } function is_even(x) { 13 return x % 2 == 0; 14 } var numbers = [0,1,2,3,4,5,6,7,8,9,10]; 17 console.log(numbers); //[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] var even_numbers = filter(numbers, is_even); 20 console.log(even_numbers); //[0, 2, 4, 6, 8, 10] At the point inside the filter()-function where the predicate()-function is called, it is not immediately clear where the control flow continues. In this simple program it is easy to find out from the context that the function is_even() will be called. However, in a real world program, a utility function like filter() will be called many times, possibly with different predicates. Thus, there is no single specific predicate function body that will be executed each time the filter() function is called. The function body that is actually executed depends on the function that is stored in the parameter predicate at the time of invocation. 5

8 1 Introduction Dynamic dispatch through inheritance in C++ Many programming languages support dynamic dispatch through inheritance. This can be used to implement polymorphic types, that is, multiple types that provide a common interface [Str14]. Listing 1.5 shows an example of dynamic dispatch in C++: Listing 1.5: Dynamic dispatch through inheritance in C++ 1 #include <iostream> 2 #include <string> 3 4 class Person { 5 std::string name; 6 public: 7 Person(std::string const& n):name{n} {} 8 virtual std::string description() const { 9 return name; 10 } 11 virtual ~Person()=default; 12 }; class Student : public Person { 15 int student_id; 16 public: 17 Student(std::string const& n, int i):person{n}, student_id{i} {} 18 std::string description() const override { 19 return Person::description() + " (" + std::to_string(student_id) + ")"; 20 } 21 }; void print(person const& p) { 24 std::cout << p.description() << std::endl; 25 } int main(int argc, char *argv[]) { 28 Person p{"toni Suter"}; 29 Student s{"toni Suter", 1234}; 30 print(p); // "Toni Suter" 31 print(s); // "Toni Suter (1234)" 32 } Like in the JavaScript example in Listing 1.4, there is not just one function body that can be executed as a result of calling p.description(). Depending on whether the argument that is passed to the function print() is a Person object or an instance of a Person subclass the results may vary. The function body that is actually executed depends on the dynamic type of the parameter p. 6

9 1 Introduction Motivation for Constraint Based Control Flow Analysis (CFA) Constraints can be used to calculate the control flow between functions (inter-flow) even for programs written in programming languages that support higher-order functions and dynamic dispatch as shown in the examples in Listing 1.4 and Listing 1.5. The general process of a Constraint Based Analysis is as follows: 1. Start with an initial solution 2. Generate a system of constraints (section 2.3) 3. Resolve the constraints to get the final solution (section 2.4) For example, in the JavaScript code in Listing 1.4, the analyser would start with an initial solution by assigning to each subexpression the set of functions that it may evaluate to. In the beginning those sets are incomplete. Constraints that describe relationships and dependencies between the sets of different subexpressions are then used to propagate the values from one set to another if necessary [Aik99]. Finally, after the constraints are resolved, the analyser knows that the parameter predicate can only evaluate to the is_even() function and may be able to perform interprocedural optimizations based on that knowledge. Therefore, control flow analysis somewhat depends on data flow analysis, because in order for the analyser to know where the control flow continues when the expression predicate(arr[i]) is executed, it has to know the values that the variable predicate can evaluate to. 7

10 2 Control flow analysis This section describes how to analyse the control flow of a program using constraints. As described in section 1.1, control flow analysis is particularly interesting in programming languages that support some form of dynamic dispatch. In this paper simple JavaScript examples are used to show the process of Constraint Based Control Flow Analysis. Some of the code is derived from the examples in the book Principles of Program Analysis [NNH99] where the untyped lambda calculus [Chu32] with a few extensions is used. 2.1 How to represent an analysis result The goal of a Constraint Based Control Flow Analysis is to determine the control flow between functions (inter-flow). As described in subsection the control flow of a program often depends on its data flow. For example, in a programming language like JavaScript where functions are first-class objects, the control flow may depend on the function that is currently stored in a variable / parameter. Therefore, the result of an analysis must contain for each subexpression the set of functions that it may evaluate to. Usually, such an analysis result is defined by a pair (Ĉ, p). The abstract cache Ĉ is a function that maps each subexpression of the program to the set of functions that it may evaluate to. The function p is called the abstract environment and it maps the variables of the program to the set of functions that may be stored in them. In order to be able to refer to each of the different subexpressions in the program they need to have a unique label. Listing 2.1 shows a simple, labelled JavaScript program: 8

11 2 Control flow analysis Listing 2.1: JavaScript example (the labels are not part of JavaScript) 1 (function apply_two(f) { 2 (return f 1 (2);) 2 3 }) (function square(x) { 6 (return x 4 * x 5 ;) 6 7 }) (function triple(y) { 10 (return y 8 + 3;) 9 11 }) (apply_two(square 11 );) (apply_two(triple 13 );) 14 The function apply_two() is a higher-order function which has one function parameter f. It calls f with the argument 2 and returns the result of this function call. The most interesting part of this program is at label 1 where dynamic dispatch happens. Table 2.1 and Table 2.2 show the analysis result in terms of the abstract cache and the abstract environment, respectively: Table 2.1: Abstract cache Ĉ Label Ĉ 1 { square, triple } 2 {} 3 { apply_two } 4 {} 5 {} 6 {} 7 { square } 8 {} 9 {} 10 { triple } 11 { square } 12 {} 13 { triple } 14 {} Table 2.2: Abstract environment p Variable p apply_two { apply_two } square { square } triple { triple } f { square, triple } x {} y {} 9

12 2 Control flow analysis The sections 2.3 and 2.4 show how one may get to such a result by generating and resolving a set of constraints. Since this is a pure control flow analysis, the result contains only function values. This is also the reason why there are so many empty sets in the result. For example, in this program the parameters x and y can only ever have the value 2. Because this is a number and not a function value it does not appear in the abstract environment p. The abstract cache for label 1 is the set { square, triple }. We therefore know, that the control flow at this point either continues in the function square() or the function triple(). As described in subsection this may enable the compiler to perform intraprocedural optimizations on a whole-program level. 2.2 Acceptability An analysis result is considered acceptable/valid, if it contains for each subexpression the set of functions that it may evaluate to. Thus, a result that contains the set of all functions for each subexpression would be a valid result, altough not a very useful one. The goal is to narrow the result down to the least solution because this increases the chances of being able to perform additional optimizations [NNH99]. There are a few simple rules that define for each type of expression (e.g. function application, binary expression, etc.) the conditions that have to be true in order for an analysis result to be valid. These rules are used to check whether an analysis result is acceptable for a particular program. Consider for example Listing 2.2: Listing 2.2: Acceptability example 1 (function my_func(f) { 2 (f 1 ();) 2 3 }) (my_func((function() { 6 //brilliant code 7 }) 4 );) 5 It should be clear, that an analysis result is only acceptable for this program, if Ĉ(4) p(f) or in other words, if the anonymous function in subexpression 4 is in the set of possible values for the parameter f. 10

13 2 Control flow analysis 2.3 Constraint generation Constraint generation is the process of building a set of constraints for a particular program. The constraints describe relationships between the abstract cache and the abstract environment of each subexpression. The goal is to generate a set of constraints and then to find the least solution that satisfies these constraints and is still considered acceptable. The constraints can be constructed by following specific rules for each kind of language construct. For example, consider the following rule var: [var] C x l = { p(x) Ĉ(l) } C is a function that maps expressions to the set of constraints that they generate. The rule var defines the constraints that are generated for expressions that consist of a single variable. In this case it s only one constraint: p(x) Ĉ(l). This means that the abstract cache Ĉ for the subexpression with the label l should at least contain all the values from the abstract environment of the variable x. In other words, if a variable x can take on a certain set of values, an expression that only consists of this variable can evaluate to the same set of values. This was a very simple example. The rule for function definition fn is a little more complex: [fn] C (function(x) { return e 0 ; }) l = {{function(x) { return e 0 ; }} Ĉ(l)} C e 0 The rule fn defines the constraints that are generated for function definitions. First, the constraint {function(x) { return e 0 ; }} Ĉ(l) is generated which causes the function value to propagate to the abstract cache of the surrounding expression with the label l. Additionally, the constraints that are generated by the expression e 0 are added to the set as well. Similar to the examples above, there are rules that define the set of constraints that needs to be generated for every language construct (e.g., function application, binary expression, etc.). 11

14 2 Control flow analysis 2.4 Constraint resolution Constraint resolution is the process in which the constraints of a program are turned into an actual analysis result. The goal of the constraint resolution is to find the least solution without actually running the program. A solution is considered to be the least solution if the abstract cache and the abstract environment are narrowed down as much as possible and the result is still acceptable Graph Formulation One way to solve a system of constraints is to build a graph from the environment p, the cache Ĉ and the constraints and then use a special algorithm to propagate the contents of the sets through the graph. Therefore, we have to start with an initial cache and environment. This initial result should contain just the values that can be identified by looking at each subexpression in isolation of the rest of the program. For example, consider the labelled JavaScript code in Listing 2.3: Listing 2.3: Graph Formulation example code 1 ((function(x) { 2 return x 1 ; 3 }) 2 ((function(y) { 4 return y 3 ; 5 }) 4 )) 5 In this simple example, an anonymous identity function is defined and immediately called with another anonymous identity function passed as argument. This may be a strange example, but longer, more meaningful programs would make it very hard to illustrate the Graph Formulation algorithm concisely. For this example, the initial result would just contain Ĉ(2) = {id x} and Ĉ(4) = {id y } where id x and id y are shorthands for the two identity functions. 12

15 2 Control flow analysis Furthermore, let s assume that there is already an existing set of constraints that was generated from rules similar to those shown in section 2.3: p(x) Ĉ(1) p(y) Ĉ(3) id x Ĉ(2) Ĉ(1) Ĉ(5) id x Ĉ(2) Ĉ(4) p(x) id y Ĉ(2) Ĉ(3) Ĉ(5) id y Ĉ(2) Ĉ(4) p(y) The following subsections describe the different steps in the Graph Formulation algorithm. Each step description contains a figure that shows the state of the graph after the step has been executed as well as an explanation of what happened. Additionally, each step title contains the state of the worklist W. The worklist W is the list of nodes that has to be processed (orange nodes in the figures). 13

16 2 Control flow analysis Step 1 : W = [Ĉ(4), Ĉ(2)] Step 1 is the starting position of the algorithm. The graph has nodes for the cache of each subexpression and for the environment of each variable. For each constraint, there is at least one directed edge in the graph that connects the nodes that are involved in this constraint. For example, the constraint p(x) Ĉ(1) is responsible for the edge that leads from the environment of the variable x to the cache of the subexpression with the label 1. Figure 2.1: Step 1 Step 2 : W = [Ĉ(4), Ĉ(2)] In step 2, some constraints are grayed out. The edges of these constraints should not be traversed by the algorithm. This is because the first part of these constraints is not true. For example, in the constraint id y Ĉ(2) Ĉ(4) p(y) the first part of the implication is not true and therefore the whole constraint is inactive. Figure 2.2: Step 2 14

17 2 Control flow analysis Step 3 : W = [p(x), Ĉ(2)] In step 3, the first node in the worklist (Ĉ(4)) is processed by traversing each of its outgoing, active edges. In this case, there is only one such edge, namely the one with the constraint id x Ĉ(2) Ĉ(4) p(x). Since the first part of the implication is true, the values in Ĉ(4) can be propagated to p(x). Additionally, the node p(x) is added to the worklist. Figure 2.3: Step 3 Step 4 : W = [Ĉ(1), Ĉ(2)] The same thing happens when the node p(x) is processed. The values in p(x) can be propagated to Ĉ(1) because of the edge that leads from p(x) to Ĉ(1). The node Ĉ(1) becomes a new member of the worklist. Figure 2.4: Step 4 15

18 2 Control flow analysis Step 5 : W = [Ĉ(5), Ĉ(2)] The constraint id x Ĉ(2) Ĉ(1) Ĉ(5) causes the values from Ĉ(1) to be propagated to the node Ĉ(5). Figure 2.5: Step 5 Step 6 : W = [] The node Ĉ(5) doesn t have any outgoing edges, so it can be removed from the worklist. The node Ĉ(2) is the only remaining member of the worklist. It can be removed too, because its outgoing edges are due to constraints that have already been processed. This is the final result of the analysis. Figure 2.6: Step 6 16

19 2 Control flow analysis Final result The tables 2.3 and 2.4 show the final result of the Graph Formulation in tabular form: Table 2.3: Abstract cache Ĉ Label Ĉ 1 {id y } 2 {id x } 3 {} 4 {id y } 5 {id y } Table 2.4: Abstract environment p Variable p x {id y } y {} This represents the least solution for the code in Listing 2.3. For example, it shows that the overall expression with the label 5 can only evaluate to the identity function id y. Since all the possible function values for each subexpression are now known, the analyser also knows which function bodies may be executed as a result of calling a function (inter-flow). In larger, more meaningful programs this knowledge may be useful to perform intraprocedural optimizations on a whole-program level as shown in subsection

20 3 Conclusion My goal for this paper was to give a brief overview over different kinds of static program analysis as well as a more detailed description of Constraint Based Control Flow Analysis (CFA). After reading this paper it should be clear to the reader that Constraint Based CFA is a powerful tool to analyse the control flow between procedures (inter-flow) which can lead to further optimization possibilities. It is worth noting that there exist more constraint based analysis techniques than the one that was described in this paper. However, explaining all of them in detail would be beyond the scope of this paper. 18

21 Bibliography [Aik99] Alexander Aiken. Introduction to Set Constraint-Based Program Analysis [ALSU06] Alfred V. Aho, Monica S. Lam, Ravi Sethi, and Jeffrey D. Ullman. Compilers - Principles, Techniques and Tools [AS96] Harold Abelson and Gerald Jay Sussman. Structure and Interpretation of Computer Programs [Chu32] Alonzo Church. A Set of Postulates for the Foundation of Logic [CT11] Keith Cooper and Linda Torczon. Engineering a Compiler [Lip11] Miran Lipovaca. Learn You a Haskell for Great Good! [NNH99] [Str14] Flemming Nielson, Hanne Riis Nielson, and Chris Hankin. Principles of Program Analysis Bjarne Stroustrup. Bjarne Stroustrup s C++ Glossary, December