Selected Aspects of Compilers

Transcription

1 Selected Aspects of Compilers Lecture Compilers SS 2009 Dr.-Ing. Ina Schaefer Software Technology Group TU Kaiserslautern Ina Schaefer Selected Aspects of Compilers 1

2 Content of Lecture 1. Introduction: Overview and Motivation 2. Syntax- and Type Analysis 2.1 Lexical Analysis 2.2 Context-Free Syntax Analysis 2.3 Context-Dependent Syntax Analysis 3. Translation to Target Language 3.1 Translation of Imperative Language Constructs 3.2 Translation of Object-Oriented Language Constructs 4. Selected Aspects of Compilers 4.1 Intermediate Languages 4.2 Optimization 4.3 Data Flow Analysis 4.4 Register Allocation 4.5 Code Generation 5. Garbage Collection 6. XML Processing (DOM, SAX, XSLT) Ina Schaefer Selected Aspects of Compilers 2

3 Outline 1. Intermediate Languages 3-Address Code Further Intermediate Languages 2. Optimization Optimization Techniques Optimization Potential 3. Data Flow Analysis Liveness Analysis Data Flow Equations Non-Local Program Analysis 4. Register Allocation Evaluation Ordering with Minimal Registers Register Allocation by Graph Coloring Further Aspects of Register Allocation 5. Code Generation Ina Schaefer Selected Aspects of Compilers 3

4 Selected Aspects of Compilers Focus: Techniques that go beyond the direct translation of source languages to target languges Concentrate on concepts instead of language-dependent details We use program representations tailored for the considered tasks (instead of source language syntax) simplifies representation but makes practical integration more difficult Ina Schaefer Selected Aspects of Compilers 4

5 Selected Aspects of Compilers (2) Educational Objectives: Intermediate languages for translation and optimization of imperative languages Different optimization techniques Different static analysis techniques for (intermediate) programs Register allocation Some aspects of code generation Ina Schaefer Selected Aspects of Compilers 5

6 Intermediate Languages Intermediate Languages Intermediate languages are used as appropriate program representation for certain language implementation tasks common representation of programs of different source languages Source Language 1 Source Language 2... Source Language n Intermediate Language Target Language 1 Target Language 2... Target Language m Ina Schaefer Selected Aspects of Compilers 6

7 Intermediate Languages Intermediate Languages (2) Intermediate languages for translation are comparable to data structures in algorithm design, i.e., for each task, an intermediate language is more or less suitable. Intermediate languages can conceptually be seen as abstract machines. Ina Schaefer Selected Aspects of Compilers 7

8 3-Address Code Intermediate Languages 3-Address Code 3-Address Code (3AC) is a common intermediate language with many variants. Properties: only elementary data types (but often arrays) no nested expressions sequential execution, jumps and procedure calls as statements named variables as in a high level language unbounded number of temporary variables Ina Schaefer Selected Aspects of Compilers 8

9 3-Address Code (2) Intermediate Languages 3-Address Code A program in 3AC consists of a list of global variables a list of procedures with parameters and local variables a main procedure each procedure has a sequence of 3AC commands as body Ina Schaefer Selected Aspects of Compilers 9

10 3AC commands Intermediate Languages 3-Address Code Syntax x := y bop z x : = uop z x:= y goto L if x cop y goto L x:= a[i] a[i]:= y x : = & a x:= *y *x := y Explanation x: variable (global, local, parameter, temporary) y,z: variable or constant bop: binary operator uop: unary operator jump or conditional jump to label L cop: comparison operator only procedure-local jumps a one-dimensional array a global, local variable or parameter & a address of a * dereferencing operator Ina Schaefer Selected Aspects of Compilers 10

11 3AC commands (2) Intermediate Languages 3-Address Code Syntax param x call p return y Explanation call p(x1,..., xn) is encoded as: (block is considered as one command) param x1... param xn call p return y causes jump to return address with (optional) result y We assume that 3AC only contains labels for which jumps are used in the program. Ina Schaefer Selected Aspects of Compilers 11

12 Basic Blocks Intermediate Languages 3-Address Code A sequence of 3AC commands can be uniquely partitioned into basic blocks. A basic block B is a maximal sequence of commands such that only one jump, procedure call and return command occurs at the end of B labels only occur at the first command of a basic block Ina Schaefer Selected Aspects of Compilers 12

13 Basic Blocks (2) Intermediate Languages 3-Address Code Remarks: The commands of a basic block are always executed sequentially, there are no jumps to the inside Often, a designated exit-block for a procedure containing the return jump at its end is required. This is handled by additional transformations. The transitions between basic blocks are often denoted by flow charts. Ina Schaefer Selected Aspects of Compilers 13

14 Intermediate Languages 3-Address Code Example: 3 AC and Basic Blocks Consider the following C program: int a[2]; int b[7]; int skprod(int i1, int i2, int lng) {... } int main( ) { a[0] = 1; a[1] = 2; b[0] = 4; b[1] = 5; b[2] = 6; skprod(0,1,2); return 0; } Ina Schaefer Selected Aspects of Compilers 14

15 Intermediate Languages 3-Address Code Example: 3 AC and Basic Blocks (2) 3AC with basic block partitioning for main procedure main: a[0] := 1 a[1] := 2 b[0] := 4 b[1] := 5 b[2] := 6 param 0 param 1 param 2 call skprod return 0 Ina Schaefer Selected Aspects of Compilers 15

16 Intermediate Languages 3-Address Code Example: 3 AC and Basic Blocks (3) Procedure skprod: int skprod(int i1, int i2, int lng) { int ix, res = 0; for( ix=0; ix <= lng-1; ix++ ){ res += a[i1+ix] * b[i2+ix]; } return res; } Ina Schaefer Selected Aspects of Compilers 16

17 Intermediate Languages 3-Address Code Example: 3 AC and Basic Blocks (4) Procedure skprod as 3AC with basic blocks skprod: res:= 0 ix := 0 t0 := lng-1 if ix<=t0 true false t1 := i1+ix t2 := a[t1] t1 := i2+ix t3 := b[t1] t1 := t2*t3 res:= es+t1 ix := ix+1 return res Ina Schaefer Selected Aspects of Compilers 17

18 Intermediate Languages 3-Address Code Intermediate Language Variations 3 AC after elimination of array operations (at above example) skprod: res:= 0 ix := 0 t0 := lng-1 if ix<=t0 true false t1 := i1+ix tx := t1*4 ta := a+tx t2 := *ta t1 := i2+ix tx := t1*4 tb := b+tx t3 := *tb t1 := t2*t3 res:= res+t1 ix := ix+1 return res Ina Schaefer Selected Aspects of Compilers 18

19 Intermediate Languages 3-Address Code Characteristics of 3-Address Code Control flow is explicit. Only elementary operations Rearrangement and exchange of commands can be handled relatively easily. Ina Schaefer Selected Aspects of Compilers 19

20 Intermediate Languages Further Intermediate Languages Further Intermediate Languages We consider 3AC in Static Single Assignment (SSA) representation Stack Machine Code Ina Schaefer Selected Aspects of Compilers 20

21 Intermediate Languages Static Single Assignment Form Further Intermediate Languages If a variable a is read at a program position, this is an application of a. If a variable a is written at a program position, this is a definition of a. For optimizations, the relationship between application and definition of variables is important. In SSA representation, each variable has exactly one definition. Thus, relationship between application and definition in the intermediate language is explicit. Ina Schaefer Selected Aspects of Compilers 21

22 Intermediate Languages Static Single Assignment Form (2) Further Intermediate Languages SSA is essentially a refinement of 3AC. The different definitions of one variable are represented by indexing the variable. For sequential command lists, this means At each definition position, the variable gets a different index. At the application position, the variable has the the index of its last definition. Ina Schaefer Selected Aspects of Compilers 22

23 Example: SSA Intermediate Languages Further Intermediate Languages a := x + y b := a 1 a := y + b b := x * 4 a := a + b a 1 := x 0 + y 0 b := a a 2 := y 0 + b 1 b 2 := x 0 * 4 a := a + b Ina Schaefer Selected Aspects of Compilers 23

24 Intermediate Languages SSA - Join Points of Control Flow Further Intermediate Languages At join points of control flow, an additional mechanism is required: a := x + y a := a b b := a 3?... Ina Schaefer Selected Aspects of Compilers 24

25 Intermediate Languages Further Intermediate Languages SSA - Join Points of Control Flow (2) Introduce an "oracle" φ that selects the value of the variable of the applicable branch: a := x + y a := a b a :=!(a,a ) b 3 := a 4... Ina Schaefer Selected Aspects of Compilers 25

26 Intermediate Languages Further Intermediate Languages SSA - Remarks The construction of an SSA representation with a minimal number of applications of the φ oracle is a non-trivial task. (cf. Appel, Sect and 19.2) The term Static Single Assignment form reflects that for each variable in the program text, there is only one assignment. Dynamically, a variable in SSA representation can be assigned arbitrarily often (e.g., in loops). Ina Schaefer Selected Aspects of Compilers 26

27 Intermediate Languages Further Intermediate Languages Further Intermediate Languages While 3AC and SSA representation are mostly used as intermediate languages in compilers, intermediate languages and abstract machines are more and more often used as connections between compilers and runtime environments. Java Byte Code and CIL (Common Intermediate Language, cf..net) are examples for stack machine code, i.e., intermediate results are stored on a runtime stack. Further intermediate languages are, for instance, used for optimizations. Ina Schaefer Selected Aspects of Compilers 27

28 Intermediate Languages Further Intermediate Languages Stack Machine Code as Intermediate Language Homogeneous Scenario for Java: Java ByteCode C1.java C2.java jikes C1.class C2.class JVM C3.java javac2 C3.class Ina Schaefer Selected Aspects of Compilers 28

29 Intermediate Languages Further Intermediate Languages Stack Machine Code as Intermediate Language (2) Inhomogeneous Scenario for.net: prog1.cs prog2.cs C# - Compiler prog1.il prog2.il CLR prog3.hs Haskell - Compiler prog3.il Ina Schaefer Selected Aspects of Compilers 29

30 Intermediate Languages Example: Stack Machine Code Further Intermediate Languages package beisp; class Weltklasse extends Superklasse implements BesteBohnen { Qualifikation studieren ( Arbeit schweiss){ return new Qualifikation(); } } Ina Schaefer Selected Aspects of Compilers 30

31 Intermediate Languages Example: Stack Machine Code (2) Further Intermediate Languages Compiled from Weltklasse.java class beisp.weltklasse extends beisp.superklasse implements beisp.bestebohnen{ beisp.weltklasse(); beisp.qualifikation studieren( beisp.arbeit); } Method beisp.weltklasse() 0 aload_0 1 invokespecial #6 <Method beisp.superklasse()> 4 return Method beisp.qualifikation studieren( beisp.arbeit ) 0 new #2 <Class beisp.qualifikation> 3 dup 4 invokespecial #5 <Method beisp.qualifikation()> 7 areturn Ina Schaefer Selected Aspects of Compilers 31

32 Intermediate Languages Further Intermediate Languages Example: Stack Machine Code - CIL '!"#$%&'()*)%&'+,%-'./()0/)1,-'2%3)'*4'%3)'#5'66'*78"9/3)(' :' ' %3)'&;'%3)'-;'%3)'/;'66'$,&*$(' ' &'<'*'='#;' ' -'<'>?;' ' ' Ina Schaefer Selected Aspects of Compilers 32

33 Intermediate Languages Further Intermediate Languages Example: Stack Machine Code - CIL (2) ' A9/)1,-'!"#$%&'1%-/#B(%8'()*)%&'+,%-''./()0/)1,-2%3)CD'*4%3)CD'#5'&%$'9*3*8/-' :' ''66'E,-/'(%F/'''''''>D'2?G&5' ''A9*G()*&H''D' ''A$,&*$('%3%)'2I?J'%3)CD'&4' '''''''''''I>J'%3)CD'-4' '''''''''''IDJ'%3)CD'/5' ''KLM????N''$-*78A?' ''KLM???>N''$-*78A>' ''KLM???DN''*--' ''KLM???CN''()$,&A?' ''KLM???ON''$-&A%OA('''>?' ''KLM???PN''()$,&A>' ''KLM???QN''$-$,&A?' ''KLM???RN''$-$,&A>' ''KLM???SN''*--' ''KLM???*N''()$,&AD' ' Ina Schaefer Selected Aspects of Compilers 33

34 Optimization Optimization Optimization refers to improving the code with the following goals: Runtime behavior Memory consumption Size of code Energy consumption Ina Schaefer Selected Aspects of Compilers 34

35 Optimization (2) Optimization We distinguish the following kinds of optimizations: and machine-independent optimizations machine-dependent optimizations (exploit properties of a particular real machine) local optimizations intra-procedural optimizations inter-procedural/global optimizations Ina Schaefer Selected Aspects of Compilers 35

36 Optimization Remark on Optimization Appel (Chap. 17, p 350): "In fact, there can never be a complete list [of optimizations]. " "Computability theory shows that it will always be possible to invent new optimizing transformations." Ina Schaefer Selected Aspects of Compilers 36

37 Constant Propagation Optimization Optimization Techniques If the value of a variable is constant, the variable can be replaced with the constant. Ina Schaefer Selected Aspects of Compilers 37

38 Constant Folding Optimization Optimization Techniques Evaluate all expressions with constants as operands at compile time. Iteration of Constant Folding and Propagation: Ina Schaefer Selected Aspects of Compilers 38

39 Optimization Non-local Constant Optimization Optimization Techniques For each program position, the possible values for each variable are required. If the set of possible values is infinite, it has to be abstracted appropriately. Ina Schaefer Selected Aspects of Compilers 39

40 Copy Propagation Optimization Optimization Techniques Eliminate all copies of variables, i.e., if there exist several variables x,y,z at a program position, that are known to have the same value, all applications of y and z are replaced by x. Ina Schaefer Selected Aspects of Compilers 40

41 Copy Propagation (2) Optimization Optimization Techniques This can also be done at join points of control flow or for loops: For each program point, the information which variables have the same value is required. Ina Schaefer Selected Aspects of Compilers 41

42 Optimization Optimization Techniques Common Subexpression Elimination If an expression or a statement contains the same partial expression several times, the goal is to evaluate this subexpression only once. Ina Schaefer Selected Aspects of Compilers 42

43 Optimization Optimization Techniques Common Subexpression Elimination (2) Optimization of a basic block is done after transformation to SSA and construction of a DAG: Ina Schaefer Selected Aspects of Compilers 43

44 Optimization Optimization Techniques Common Subexpression Elimination (3) Remarks: The elimination of repeated computations is often done before transformation to 3AC, but can also be reasonable following other transformations. The DAG representation of expressions is also used as intermediate language by some authors. Ina Schaefer Selected Aspects of Compilers 44

45 Optimization Algebraic Optimizations Optimization Techniques Algebraic laws can be applied in order to be able to use other optimizations. For example, use associativity and commutativity of addition: Caution: For finite data type, common algebraic laws are not valid in general. Ina Schaefer Selected Aspects of Compilers 45

46 Strength Reduction Optimization Optimization Techniques Replace expensive operations by more efficient operations (partially machine-dependent). For example: y: = 2* x can be replaced by y : = x + x or by y: = x «1 Ina Schaefer Selected Aspects of Compilers 46

47 Optimization Optimization Techniques Inline Expansion of Procedure Calls Replace call to non-recursive procedure by its body with appropriate substitution of parameters. Note: This reduces execution time, but increases code size. Ina Schaefer Selected Aspects of Compilers 47

48 Optimization Optimization Techniques Inline Expansion of Procedure Calls (2) Remarks: Expansion is in general more than text replacement: Ina Schaefer Selected Aspects of Compilers 48

49 Optimization Optimization Techniques Inline Expansion of Procedure Calls (3) In OO programs with relatively short methods, expansion is an important optimization technique. But, precise information about the target object is required. A refinement of inline expansion is the specialization of procedures/functions if some of the current parameters are known. This technique can also be applied to recursive procedures/functions. Ina Schaefer Selected Aspects of Compilers 49

50 Dead Code Elimination Optimization Optimization Techniques Remove code that is not reached during execution or that has no influence on execution. In one of the above examples, constant folding and propagation produced the following code: Provided, t3 and t4 are no longer used after the basic block (not live). Ina Schaefer Selected Aspects of Compilers 50

51 Optimization Dead Code Elimination (2) Optimization Techniques A typical example for non-reachable and thus, dead code that can be eliminated: Ina Schaefer Selected Aspects of Compilers 51

52 Optimization Dead Code Elimination (3) Optimization Techniques Remarks: Dead code is often caused by optimizations. Another source of dead code are program modifications. In the first case, liveness information is the prerequiste for dead code elimination. Ina Schaefer Selected Aspects of Compilers 52

53 Optimization Optimization Techniques Code Motion Move commands between branches such that commands get are in basic blocks that are less often executed. We consider two cases: Move commands in succeeding or preceeding branches Move code out of loops Optimization of loops is very profitable, because code inside loops is executed more often than code not contained in a loop. Ina Schaefer Selected Aspects of Compilers 53

54 Optimization Optimization Techniques Move Code between Execution Branches If a sequential computation branches, the branches are less often executed than the sequence. Ina Schaefer Selected Aspects of Compilers 54

55 Optimization Optimization Techniques Move Code between Execution Branches (2) Prerequisite for this optimization is that a defined variable is only used in one branch. Moving the command to a preceeding branch is reasonable, if the command can be removed from one branch. Ina Schaefer Selected Aspects of Compilers 55

56 Optimization Partial Redundancy Elimination Optimization Techniques Definition (Partial Redundancy) An assignment is redundant at a program position s, if it has already been executed on all paths to s. An expression e is redundant at s, if the value of e has already been calculated on all paths to s. An assignment/expression is partially redundant at s, if it is redundant with respect to some execution paths leading to s. Ina Schaefer Selected Aspects of Compilers 56

57 Optimization Optimization Techniques Partial Redundancy Elimination (2) Example: Ina Schaefer Selected Aspects of Compilers 57

58 Optimization Optimization Techniques Partial Redundancy Elimination (3) Elimination of partial redundancy: Ina Schaefer Selected Aspects of Compilers 58

59 Optimization Optimization Techniques Partial Redundancy Elimination (4) Remarks: PRE can be seen as a combination and extension of common subexpression elimination and code motion. Extension: Elimination of partial redundancy according to estimated probability for execution of specific paths. Ina Schaefer Selected Aspects of Compilers 59

60 Optimization Code Motion from Loops Optimization Techniques Idea: Computations in loops whose operations are not changed inside the loop should be done outside the loop. Provided, t1 is not live at the end of the top-most block on the left side. Ina Schaefer Selected Aspects of Compilers 60

61 Optimization Optimization of Loop Variables Optimization Techniques Variables and expressions that are not changed during the execution of a loop are called loop invariants. Loops often have variables that are increased/decreased systematically in each loop execution, e.g., for-loops. Often, a loop variable depends on another loop variable, e.g., a relative address depends on the loop counter variable. Ina Schaefer Selected Aspects of Compilers 61

62 Optimization Optimization Techniques Optimization of Loop Variables (2) Definition (Loop Variables) A variable i is called explicit loop variable of a loop S, if there is exactly one definition of i in S of the form i := i + c where c is a loop invariant. A variable k is called derived loop variable of a loop S, if there is exactly one definition of k in S of the form k := j * c or k := j + d where j is a loop variable and c and d are loop invariants Ina Schaefer Selected Aspects of Compilers 62

63 Optimization Induction Variable Analysis Optimization Techniques Compute derived loop variables inductively, i.e., instead of computing them from the value of the loop variable, compute them from the valued of the previous loop execution. Note: For optimization of derived loop variables, dependencies between variable definitions have to be considered precisely. Ina Schaefer Selected Aspects of Compilers 63

64 Loop Unrolling Optimization Optimization Techniques If the number of loop executions is known statically or properties about the number of loop executions (e.g., always an even number) can be inferred, the loop body can be copied several times to save comparisons and jumps. Provided, ix is dead at the end of the fragment. Note,the static computation of ix in the unrolled loop. Ina Schaefer Selected Aspects of Compilers 64

65 Loop Unrolling (2) Optimization Optimization Techniques Remarks: Partial loop unrolling aims at obtaining larger basic blocks in loops to have more optimization options. Loop unrolling is in particular important for parallel processor architectures and pipelined processing (machine-dependent). Ina Schaefer Selected Aspects of Compilers 65

66 Optimization Optimization Techniques Optimization for Other Language Classes The discussed optimizations aim at imperative languages. For optimizing programs of other language classes, special techniques have been developed. For example: Object-oriented languages: Optimization of dynamic binding (type analysis) Non-strict functional languages: Optimization of lazy function calls (strictness analysis) Logic programming languages: Optimization of unification Ina Schaefer Selected Aspects of Compilers 66

67 Optimization Optimization Potential Optimization Potential - Example Consider procedure skprod for the evaluation of the optimization techniques: Evaluation: Number of steps (lng): * lng +1 = 13 lng + 5 Ina Schaefer Selected Aspects of Compilers 67

68 Optimization Optimization Potential Optimization Potential - Example (2) Move computation of loop invariant out of loop: Evaluation: *lng+1 = 12 *lng + 5 Ina Schaefer Selected Aspects of Compilers 68

69 Optimization Optimization Potential Optimization Potential - Example (3) Optimization of loop variables: There are no derived loop variables, because t1 and tx have several definitions; Transformation to SSA for t1 and tx yields that t11, tx1, ta, t12, tb become derived loop variables. Ina Schaefer Selected Aspects of Compilers 69

70 Optimization Optimization Potential Optimization Potential - Example (4) Optimization of loop variables(2): Inductive definition of loop variables Ina Schaefer Selected Aspects of Compilers 70

71 Optimization Optimization Potential Optimization Potential - Example (5) Dead Code Elimination: t11, tx1, t12, tx2 do not influence the result. Evaluation: * lng +1 = 8 * lng +11 Ina Schaefer Selected Aspects of Compilers 71

72 Optimization Optimization Potential Optimization Potential - Example (6) Algebraic Optimizations: Use invariants ta = 4 (i1 1 + ix)+a for the comparison ta 4 (i1 1 + t0)+a Ina Schaefer Selected Aspects of Compilers 72

73 Optimization Optimization Potential Optimization Potential - Example (7) Dead Code Elimination: Assignment to ix is dead code and can be eliminated. Evaluation: * Ing +1 = 7 * lng + 13 Ina Schaefer Selected Aspects of Compilers 73

74 Optimization Optimization Potential Optimization Potential - Example (8) Remarks: Reduction of execution steps by almost half, where the most significant reductions are achieved by loop optimization. Combination of optimization techniques is important. Determining the ordering of optimizations is in general difficult. We have only considered optimizations at examples. The difficulty is to find algorithms and heuristics for detecting optimization potential automatically and for executing the optimizing transformations. Ina Schaefer Selected Aspects of Compilers 74

75 Data Flow Analysis Data Flow Analysis For optimizations, data flow information is required that can be obtained by data flow analysis. Goal: Explanation of basic concepts of data flow analysis at examples Outline: Liveness analysis (Typical example of data flow analysis) Data flow equations Important Analyses Classes Each analysis has an exact specification which information it provides. Ina Schaefer Selected Aspects of Compilers 75

76 Liveness Analysis Data Flow Analysis Liveness Analysis Definition (Liveness Analysis) Let P be a program. A variable v is live at a program position S, if there is an execution path from S on which an application of v preceds a definition of v. The liveness analysis determines for al positions S in P which variables are live at S. Ina Schaefer Selected Aspects of Compilers 76

77 Liveness Analysis (2) Data Flow Analysis Liveness Analysis Remarks: The definition of liveness of variables is static/syntactic. We have defined dead code dynamically/semantically. The result of the liveness analysis for a programm P can be represented as a function live mapping positions in P to bit vectors, where a bit vector contains an entry for each variable in P. Let i be the index of a variable in P, then it holds that: live(s)[i] =1 iff v is live at position s Ina Schaefer Selected Aspects of Compilers 77

78 Liveness Analysis (3) Data Flow Analysis Liveness Analysis Idea: For a procedure-local analysis, at the end of the procedure the global variables are live. If the live variables out(b) at the end of a basic block B are known, the live variables in(b) at the beginning of B are computed by: in(b) =gen(b) (out(b) \ kill(b)) where gen(b) is the set of variables v such that v is applied in B without a prior definition of v kill(b) is the set of variables that are defined in B Ina Schaefer Selected Aspects of Compilers 78

79 Liveness Analysis (4) Data Flow Analysis Liveness Analysis As the set in(b) is computed from out(b), we have a backward analysis. out(b) is obtained by out(b) = in(b i ) for all successors B i of B For a program without loops, in and out for all basic blocks are defined. Otherwise, we obtain a recursive system of equations. Ina Schaefer Selected Aspects of Compilers 79

80 Data Flow Analysis Liveness Analysis - Example Liveness Analysis Question: How do we compute out(b2)? Ina Schaefer Selected Aspects of Compilers 80

81 Data Flow Analysis Data Flow Equations Data Flow Equations Theory: There is always a solution for the equations of the considered form. There is always a smallest solution that is obtained by an iteration starting from empty in and out sets. Note: The solution is not necessarily unique. Ina Schaefer Selected Aspects of Compilers 81

82 Data Flow Analysis Data Flow Equations Ambiguity of Solutions - Example Thus, out(b0) =in(b0) and in(b0) ={a} in(b0). Possible Solutions: in(b0) ={a} or in(b0) ={a, b} Ina Schaefer Selected Aspects of Compilers 82

83 Data Flow Analysis Data Flow Equations Computation of Smallest Fixpoint 1. Compute gen(b), kill(b) for all B. 2. Set out(b) = for all B except for the exit block. For the exit block, out(b) comes from the program context. 3. While out(b) or in(b) changes for any B: Compute in(b) from current out(b) for all B. Compute out(b) from in(b) of its successors. Ina Schaefer Selected Aspects of Compilers 83

84 Data Flow Analysis Data Flow Equations Further Analyses Classes Many data flow analyses can be described as bit vector problems: Reaching definitions: Which definitions reach a position S? Available expressions for elimination of repeated computations Very busy expressions: Which expression is needed for the subsequent computations? The according analyses can be treated analogue to liveness analysis, but differ in the definition of the data flow information the definition of gen and kill the direction of the analysis and the equations Ina Schaefer Selected Aspects of Compilers 84

85 Data Flow Analysis Further Analyses Classes (2) Data Flow Equations For backward analyses, the data flow information at the entry of a basic block B is obtained from the information at the exit of B: in(b) =gen(b) (out(b) \ kill(b)) Analyses can be distinguished if they consider the conjunction or the intersection of the successor information: or out(b) = out(b) = B i succ(b) B i succ(b) in(b i ) in(b i ) Ina Schaefer Selected Aspects of Compilers 85

86 Data Flow Analysis Further Analyses Classes (3) Data Flow Equations For forward analyses, the dependency is the other way round: out(b) =gen(b) (in(b) \ kill(b)) with or in(b) = out(b i ) B i pred(b) in(b) = out(b i ) B i pred(b) Ina Schaefer Selected Aspects of Compilers 86

87 Data Flow Analysis Data Flow Equations Further Analyses Classes (4) Overview of Analysis Classes: conjunction intersection forward reachable definitions available expressions backward live variables busy expressions Ina Schaefer Selected Aspects of Compilers 87

88 Data Flow Analysis Further Analyses Classes (5) Data Flow Equations For bit vector problems, data flow information consists of subsets of finite sets. For other analyses, the collected information is more complex, e.g., for constant propagation, we consider mappings from variables to values. For interprocedural analyses, complexity increases because the flow graph is not static. Formal basis for the development and correctness of optimizations is provided by the theory of abstract interpretation. Ina Schaefer Selected Aspects of Compilers 88

89 Data Flow Analysis Non-Local Program Analysis Non-Local Program Analysis At the example of a points-to analysis, we consider interprocedural aspects: The analysis crosses the borders of single procedures. constraints: Program analysis very often involves solving or refining constraints. complex analysis results: The analysis result cannot be represented locally for a statement. analysis as abstraction: The result of the analysis is an abstraction of all possible program executions. Ina Schaefer Selected Aspects of Compilers 89

90 Data Flow Analysis Non-Local Program Analysis Points-to Analysis Analysis for programs with pointers and for object-oriented programs Goal: Compute which references to which records/objects a variable can hold. Applications of Analysis Results: Basis for optimizations Alias information (e.g., important for code motion) Can p.f = x cause changes to an object referenced by q? Can z = p.f read information that is written by p.f = x? Call graph construction Resolution of virtual method calls Escape analysis Ina Schaefer Selected Aspects of Compilers 90

91 Alias Information Data Flow Analysis Non-Local Program Analysis (1) p.f = x; (2) y = q.f; (3) q.f = z; p == q: (1) (2) y = x; (3) q.f = z; p!= q: First two statements can be switched. Erste Anweisung lässt sich m anderen beiden vertauschen Ina Schaefer Selected Aspects of Compilers 91

92 Data Flow Analysis Elimination of Dynamic Binding Non-Local Program Analysis class A { void m(... ) {... } } class B extends A { void m(... ) {... } }... A p; p = new B(); p.m(...) // Aufruf von B:: Call of B::m Ina Schaefer Selected Aspects of Compilers 92

93 Escape Analysis Data Flow Analysis Non-Local Program Analysis R m( A p ) { B q; q = new B(); // Kellerverwaltung Can be stored on stack mög q.f = p; q.g = p.n(); return q.g; } Ina Schaefer Selected Aspects of Compilers 93

94 Data Flow Analysis A Points-to Analysis for Java Non-Local Program Analysis Simplifications Complete program is known. Only assignments and method calls of the following form are used: Direct assignment: l = r Write to instance variables: l.f = r Read of instance variables: l = r.f Object creation: l = new C() Simple method call: l = r0.m(r1,...) Expressions without side effects Nested Expressions Ina Schaefer Selected Aspects of Compilers 94

95 Data Flow Analysis A Points-to Analysis for Java (2) Non-Local Program Analysis Analysis Type Flow-insensitive: The control flow of the program has no influence on the analysis result. The states of the variables at different program points are combined. Context-insensitive: Method calls at different program points are not distinguished. Ina Schaefer Selected Aspects of Compilers 95

96 Data Flow Analysis Non-Local Program Analysis A Points-to Analysis for Java (3) Points-to Graph as Abstraction Result of the analysis is a points-to graph with abstract variables and abstract objects as nodes edges represent that an abstract variable may have a reference to an abstract object Abstract variables V represent sets of concrete variables at runtime. Abstract objects O represent sets of concrete objects at runtime. An edge between V and O means, that in a certain program state, a concrete variable in V may reference an object in O. Ina Schaefer Selected Aspects of Compilers 96

97 Data Flow Analysis Points-to Graph - Example Non-Local Program Analysis class Y {... } class X { Y f; void set( Y r ) { this.f = r; } static void main() { X p = new X(); // s1 erzeugt o1 Y q = new Y(); // s2 erzeugt o2 p.set(q); } } Ina Schaefer Selected Aspects of Compilers 97

98 Data Flow Analysis Points-to Graph - Example (2) Non-Local Program Analysis Ina Schaefer Selected Aspects of Compilers 98

99 Data Flow Analysis Definition of the Points-to Graph Non-Local Program Analysis For all method implementations, create node o for each object creation create nodes for each local variable v each formal parameter p of any method (incl. this and results (ret)) each static variable s (Instance variables are modeled by labeled edges.) Ina Schaefer Selected Aspects of Compilers 99

100 Data Flow Analysis Non-Local Program Analysis Definition of the Points-to Graph (2) Edges: Smallest Fixpoint of f : PtGraph Stmt PtGraph with f (G, l = new C()) = G {(l, o i )} f (G, l = r) =G {(l, o i ) o i Pt(G, r)} f (G, l.f = r) =G {(< o i, f >, o j ) o i Pt(G, l), o j Pt(G, r)} f (G, l = r.f )=G {(l, o i ) o j Pt(G, r).o i Pt(G,<o j, f >)} f (G, l = r 0.m(r 1,..., r n )) = G o i Pt(G,r 0 ) solve(g, m, o i, r 1,..., r n, l) where Pt(G, x) is the points-to set of x in G, solve(g, m, o i, r 1,..., r n, l) = let m j (p 0, p 1,..., p n, ret j )=dispatch(o i, m) in {(p 0, o i )} f (G, p 1 = r 1 )... f (G, l = ret j ) end and dispatch(o i, m) returns the actual implementation of m for o i with formal parameters p 1,..., p n, result variable ret j, p 0 refers to this. Ina Schaefer Selected Aspects of Compilers 100

101 Data Flow Analysis Non-Local Program Analysis Definition of the Points-to Graph (3) Remark: The main problem for practical use of the analysis is the efficient implementation of the computation of the points-to graph. Literature: A. Rountev, A. Milanova, B. Ryder: Points-to Analysis for Java Using Annotated Constraints. OOPSLA Ina Schaefer Selected Aspects of Compilers 101