4. Selected Topics in Compiler Construction

Transcription

1 Content of Lecture Compilers and Language Processing Tools Summer Term 011 Prof. Dr. Arnd Poetzsch-Heffter Software Technology Group TU Kaiserslautern c Prof. Dr. Arnd Poetzsch-Heffter 1 1. Introduction. Syntax and Type Analysis.1 Lexical Analysis. Context-Free Syntax Analysis.3 Context-Dependent Analysis 3. Translation to Target Language 3.1 Translation of Imperative Language Constructs 3. Translation of Object-Oriented Language Constructs 4. Selected Topics in Compiler Construction 4.1 Intermediate Languages Just-in-time Compilation 4.5 Further Aspects of Compilation 5. Garbage Collection 6. XML Processing (DOM, SAX, XSLT) c Prof. Dr. Arnd Poetzsch-Heffter Chapter Outline 4. Selected Topics in Compiler Construction 4. Selected Topics in Compiler Construction 4.1 Intermediate Languages Address Code 4.1. Other Intermediate Languages Classical Techniques 4.. Potential of s 4..3 Data Flow Analysis 4..4 Non-local Sethi-Ullman Algorithm 4.3. by Graph Coloring 4.4 Just-in-time Compilation 4.5 Further Aspects of Compilation c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 3 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 4 Selected topics in compiler construction Selected topics in compiler construction () Focus: Techniques that go beyond the direct translation of source languages to target languages Concentrate on concepts instead of language-dependent details Use program representations tailored for the considered tasks (instead of source language syntax): simplifies representation (but needs more work to integrate tasks) Learning objectives: for translation and optimization of imperative languages Different optimization techniques Different static analysis techniques for (intermediate) programs Register allocation Some aspects of code generation c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 5 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction are used as appropriate program representation for certain language implementation tasks common representation of programs of different source languages Source Language 1 Source Language... Source Language n Intermediate Language Target Language 1 Target Language... Target Language m c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 7 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 8

2 () 3-Address Code for translation are comparable to data structures in algorithm design, i.e., for each task, an intermediate language is more or less suitable. can conceptually be seen as abstract machines Address Code c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 9 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 10 3-Address Code 3-Address Code 3-address code 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 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 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 11 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 1 3-Address Code 3-Address Code 3AC commands 3AC commands () 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 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. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 13 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 14 3-Address Code 3-Address Code Basic blocks Basic blocks () A sequence of 3AC commands can be uniquely partitioned into basic blocks. A basic block B is a maximal sequence of commands such that at the end of B, exactly one jump, procedure call, or return command occurs labels only occur at the first command of a basic block 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. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 15 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 16

3 int a[]; int b[7]; int skprod(int i1, int i, int lng) {... 3-Address Code Example: 3AC and basic blocks Beispiel: (3AC und Basisblöcke) Consider the following C program: Wir betrachten den 3AC für ein C-Programm: int a[]; int b[7]; int skprod(int i1, int i, int lng) {... int main( ) { a[0] = 1; a[1] = ; b[0] = 4; b[1] = 5; b[] = 6; skprod(0,1,); return 0; 3AC mit Basisblockzerlegung für die Prozedur main: main: c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 17 a[0] := 13-Address Code a[1] := Example: 3AC and basic b[0] := blocks 4 (3) b[1] := 5 b[] := 6 param 0 param 1 Procedure param Prozedur skprod: skprod mit 3AC und Basisblockzerlegung: call skprod int skprod(int i1, int i, int lng) { return 0 int ix, res = 0; for( ix=0; ix <= lng-1; ix++ ){ A. Poetzsch-Heffter, TU Kaiserslautern 96 res += a[i1+ix] * b[i+ix]; return res; skprod: int main( ) { a[0] = 1; a[1] = ; 3-Address Code b[0] = 4; b[1] = 5; b[] = 6; skprod(0,1,); return 0; Example: 3AC and basic blocks () 3AC with basic block partitioning for main procedure 3AC mit Basisblockzerlegung für die Prozedur main: main: a[0] := 1 a[1] := b[0] := 4 b[1] := 5 b[] := 6 param 0 param 1 param call skprod return A. Poetzsch-Heffter, TU Kaiserslautern 96 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 18 3-Address Code Prozedur skprod mit 3AC und Basisblockzerlegung: Example: 3AC and basic blocks (4) int skprod(int i1, int i, int lng) { int ix, res = 0; for( ix=0; ix <= lng-1; ix++ ){ res += a[i1+ix] * b[i+ix]; Procedure skprod as 3AC with basic blocks return res; true t1 := i1+ix t := a[t1] t1 := i+ix t3 := b[t1] t1 := t*t3 res:= es+t1 ix := ix+1 skprod: res:= 0 ix := 0 t0 := lng-1 if ix<=t0 false return res res:= 0 ix := 0 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 19 t0 := lng-1 Variation im Rahmen if einer ix<=t0 Zwischensprache: 3 AC after elimination of array true operations (atfalse above example) p t1 := i1+ix t := a[t1] t1 := i+ix t3 := b[t1] t1 := t*t3 res:= es+t1 true ix := ix+1 3-Address Code Intermediate Language Variations 3-Adress-Code nach Elimination von Feldoperationen anhand des obigen Beispiels: skprod: res:= 0 ix := 0 t0 := lng-1 if ix<=t0 false return res t1 := i1+ix tx := t1*4 ta := a+tx t := *ta t1 := i+ix tx := t1*4 tb := b+tx t3 := *tb return res t1 := t*t3 res:= res+t ix := ix+1 A. Poetzsch-Heffter, TU Kaiserslautern A. Poetzsch-Heffter, TU Kaiserslautern 97 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 0 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. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction A. Poetzsch-Heffter, TU Kaiserslautern 98 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction Other Intermediate Languages Further Intermediate Languages Other Intermediate Languages 4.1. Other Intermediate Languages We consider 3AC in Static Single Assignment (SSA) representation Stack Machine Code c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 3 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 4

4 Other Intermediate Languages In SSA-Repräsentation besitzt jede Variable genau Single eine Definition. Static Assignment Dadurch Form wird der Zusammenhang zwischen Anwendung ng und Definition in der Zwischensprache explizit, d.h. eine zusätzliche Ifdef-use-Verkettung a variable a is read at a program oder use-def-verkettung position, this is a of a. wird unnötig. If a variable a is written at a program position, this is a definition of a. SSA ist im Wesentlichen eine Verfeinerung von 3AC. For optimizations, the relationship between use and definition of variables is important. Die Unterscheidung zwischen den Definitionsstellen wird häufig durch Indizierung der Variablen dargestellt. In SSA representation, each variable has exactly one definition. Thus, relationship between use and definition in the intermediate language is explicit. Für sequentielle Befehlsfolgen bedeutet das: An jeder Definitionsstelle bekommt die Variable einen anderen Index. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 5 An der Anwendungsstelle wird die Variable mit Other Intermediate Languages Example: dem Index SSA der letzten Definitionsstelle notiert. Beispiel: An Stellen, an denen der Kontrollfluß zusammen- führt, bedarf es eines zusätzlichen Mechanismus: a := x + y b := a 1 a := a := y + x b+ y b := x * 4 a := a + b b := a 3?... a := x + y b := a a := a y + b b 3 b := x 0 * 4 a := a + b A. Poetzsch-Heffter, TU Kaiserslautern 300 Single Static Assignment Form () SSA is essentially a refinement of 3AC. Other Intermediate Languages The different definitions of one variable are represented by indexing the variable. For sequential command lists, this means that at each definition position, the variable gets a different index. at the use position, the variable has the index of its last definition. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 6 Other Intermediate Languages An SSA Stellen, - Join an Points denen of Control der Kontrollfluß Flow zusammen- führt, bedarf es eines zusätzlichen Mechanismus: At join points of control flow, an additional mechanism is required: a := x + y b := a 3?... a := a b 3 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 7 Other Intermediate Languages Einführung der fiktiven Orakelfunktion Orakelfunktion!,! die SSA - Join Points of Control Flow () quasi den Wert der Variable im zutreffenden Zweig auswählt: Introduce an "oracle" Φ that selects the value of the variable of the use branch: a := x + y a :=!(a,a ) b 3 := a 4... a := a b 3 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 8 Einführung der fiktiven Orakelfunktion Orakelfunktion!,! die Other Intermediate Languages quasi SSA -den Remarks Wert der Variable im zutreffenden Zweig auswählt: a := x + y a := a b 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.) The term single static 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). a :=!(a,a ) b 3 := a A. Poetzsch-Heffter, TU Kaiserslautern 301 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 9 Other Intermediate Languages c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 30 Other Intermediate Languages A. Poetzsch-Heffter, TU Kaiserslautern 301 Further intermediate languages Stack machine code as intermediate language 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. Homogeneous Sprachlich scenario homogenes for Java: Szenario bei Java: Java C1.java C.java C3.java jikes javac ByteCode C1.class C.class C3.class JVM Sprachlich ggf. inhomogenes Szenario bei.net: c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 31 Programme verschiedener Hochsprachen Intermediate Language c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 3 prog1.cs C# - prog1.il

5 JVM C3.java javac C3.class Other Intermediate Languages Stack Sprachlich machine ggf. code inhomogenes as intermediate Szenario language bei.net:() Example: Stack machine code Other Intermediate Languages Programme verschiedener Intermediate Inhomogeneous Hochsprachen scenario for.net: Language prog1.cs prog.cs prog3.hs C# - Compiler Haskell - Compiler prog1.il prog.il prog3.il CLR Beispiel: (Kellermaschinencode) package beisp; class Weltklasse extends Superklasse implements BesteBohnen { Qualifikation studieren ( Arbeit schweiss){ return new Qualifikation(); Java-ByteCode und die MS-Intermediate Language Beispiel: (Kellermaschinencode) sind Beispiele für Kellermaschinencode, d.h. package beisp; Zwischenergebnisse i werden auf einem Laufzeitkeller class Weltklasse extends Superklasse verwaltet. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 33 implements Other Intermediate BesteBohnen Languages { Qualifikation studieren ( Arbeit schweiss){ Example: Stack machine code () return new Qualifikation(); A. Poetzsch-Heffter, TU Kaiserslautern 303 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 # <Class beisp.qualifikation> 3 dup 4 invokespecial #5 <Method beisp.qualifikation()> 7 areturn Bemerkung: Weitere Zwischensprachen werden insbesondere auch im Zusammenhang mit Optimierungen eingesetzt. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction A. Poetzsch-Heffter, TU Kaiserslautern 304 Compiled from Weltklasse.java class beisp.weltklasse extends beisp.superklasse implements beisp.bestebohnen{ beisp.weltklasse(); beisp.qualifikation studieren( beisp.arbeit); c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 34 Method beisp.weltklasse() 0 aload_0 1 invokespecial #6 <Method beisp.superklasse()> 4 return Method beisp.qualifikation studieren( beisp.arbeit ) 0 new # <Class beisp.qualifikation> 3 dup 4 invokespecial 4. #5 <Method beisp.qualifikation()> 7 areturn Bemerkung: Weitere Zwischensprachen werden insbesondere auch im Zusammenhang mit Optimierungen eingesetzt A. Poetzsch-Heffter, TU Kaiserslautern 304 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 36 () refers to improving the code with the following goals: Runtime behavior Memory consumption Size of code Energy consumption 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 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 37 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 38 Remark on Classical Techniques 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." 4..1 Classical Techniques c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 39 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 40

6 Constant Propagation Classical Techniques Classical Techniques Constant Folding Evaluate all expressions with constants as operands at compile time. If the value of a variable is constant, the variable can be replaced with the constant. Iteration of Constant Folding and Propagation: c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 41 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 4 Non-local Constant Classical Techniques Copy Propagation Classical 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 uses of y and z are replaced by x. 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. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 43 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 44 Copy Propagation () Classical Techniques Classical Techniques Common Subexpression Elimination This can also be done at join points of control flow or for loops: If an expression or a statement contains the same partial expression several times, the goal is to evaluate this subexpression only once. For each program point, the information which variables have the same value is required. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 45 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 46 Classical Techniques Common Subexpression Elimination () Classical Techniques Common Subexpression Elimination (3) of a basic block is done after transformation to SSA and construction of a DAG: 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. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 47 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 48

7 Classical Techniques Classical Techniques Algebraic s Strength Reduction Algebraic laws can be applied in order to be able to use other optimizations. For example, use associativity and commutativity of addition: Replace expensive operations by more efficient operations (partially machine-dependent). For example: y: = * x can be replaced by y : = x + x Caution: For finite data type, common algebraic laws are not valid in general. or by y: = x «1 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 49 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 50 Classical Techniques Inline Expansion of Procedure Calls Classical Techniques Inline Expansion of Procedure Calls () Replace call to non-recursive procedure by its body with appropriate substitution of parameters. Remarks: Expansion is in general more than text replacement: Note: This reduces execution time, but increases code size. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 51 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 5 Classical Techniques Inline Expansion of Procedure Calls (3) Dead Code Elimination Classical Techniques 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. 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). c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 53 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 54 Classical Techniques Classical Techniques Dead Code Elimination () Dead Code Elimination (3) A typical example for non-reachable and thus, dead code that can be eliminated: 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. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 55 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 56

8 Code motion Classical Techniques Move code over branching points Classical Techniques Move commands over branching points in the control flow graph such that they end up in basic blocks that are less often executed. If a sequential computation branches, the branches are less often executed than the sequence. We consider two cases: Move commands in succeeding or preceeding branches Move code out of loops of loops is very profitable, because code inside loops is executed more often than code not contained in a loop. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 57 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 58 Classical Techniques Move code over branching points () Partial redundancy elimination Classical Techniques Prerequisite for this optimization is that a defined variable is only used in one branch. Moving the command over a preceeding joint point can be advisable, if the command can be eliminated by optimization from one of the branches. 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. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 59 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 60 Partial redundancy elimination () Classical Techniques Partial redundancy elimination (3) Classical Techniques Example: Elimination of partial redundancy: c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 61 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 6 Partial redundancy elimination (4) Classical Techniques Code motion from loops Classical Techniques Idea: Computations in loops whose operations are not changed inside the loop should be done outside the loop. 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. Provided, t1 is not live at the end of the top-most block on the left side. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 63 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 64

9 of loop variables Classical Techniques of loop variables () Classical Techniques Variables and expressions that are not changed during the execution of a loop are called loop invariant. 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. 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 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 invariant. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 65 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 66 Induction variable analysis Classical 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. Loop unrolling Classical 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. Note: For optimization of derived loop variables, the dependencies between variable definitions have to be precisely understood. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 67 Provided, ix is dead at the end of the fragment. Note, the static computation of ix s values in the unrolled loop. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 68 Loop unrolling () Classical Techniques Classical Techniques for other language classes 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). The discussed optimizations aim at imperative languages. For optimizing programs of other language classes, special techniques have been developed. For example: Object-oriented languages: of dynamic binding (type analysis) Non-strict functional languages: of lazy function calls (strictness analysis) Logic programming languages: of unification c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 69 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 70 Potential of s Potential of s Potential of optimizations - Example Consider procedure skprod for the evaluation of the optimization techniques: sen Bewertung. skprod: 4.. Potential of s res:= 0 ix := 0 t0 := lng-1 if ix<=t0 true t1 := i1+ix tx := t1*4 ta := a+tx t := *ta t1 := i+ix tx := t1*4 tb := b+tx t3 := *tb t1 := t*t3 res:= res+t1 ix := ix+1 false return res Evaluation: Number of steps depending on lng: lng + 1 = 13 lng + 5 lng=100: 1305 lng=1000: c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 71 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 7

10 Potential of s Potential of optimizations - Example () Move computation of Herausziehen loop invariant der Berechnung out der of loop: Schleifeninvariante t0: true t1 := i1+ix tx := t1*4 ta := a+tx t := *ta t1 := i+ix tx := t1*4 tb := b+tx t3 := *tb t1 := t*t3 res:= res+t1 ix := ix+1 skprod: res:= 0 ix := 0 t0 := lng-1 if ix<=t0 Evaluation: 3+1+1*lng+1 = 1 *lng + 5 false return res Bewertung: *lng + 1 = 1*lng + 5 ( lng = 100: 105, lng = 1000: 1005 ) c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction A. Poetzsch-Heffter, TU Kaiserslautern 33 Potential of s Potential of optimizations - Example (4) Optimierung von Schleifenvariablen (): of loop variables(): Inductive definition of loop variables Initialisierung und induktive Definition der Schleifenvariablen: i skprod: Potential of s Potential of optimizations - Example (3) of loop variables: Optimierung von There Schleifenvariablen are no (1): derived loop variables, because Zunächst gibt es keine abgeleiteten Schleifenvariablen, t1 and tx have several definitions; transformation to SSA for t1 and tx yields da t1 und tx mehrere Definitionen besitzen; Einführen that t11, tx1, ta, t1, tbvon become SSA für t1 und derived tx macht t11, loop tx1, variables. ta, t1, tx, tb zu abgeleiteten Schleifenvariablen: true t11:= i1+ix tx1:= t11*4 ta := a+tx1 t := *ta t1:= i+ix tx:= t1*4 tb := b+tx t3 := *tb t13:= t*t3 res:= res+t13 ix := ix+1 skprod: res:= 0 ix := 0 t0 := lng-1 if ix<=t0 false return res c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics A. Poetzsch-Heffter, in Compiler TU Kaiserslautern Construction Potential of s Potential of optimizations - Example (5) Elimination toten Codes: Dead Code Elimination: Die Zuweisungen t11, tx1, an t1, tx do not influence the result. t11, tx1, t1, tx sind toter Code, da sie das Ergebnis nicht beeinflussen. skprod: res:= 0 ix := 0 t0 := lng-1 t11:= i1-1 tx1:= t11*4 ta := a+tx1 t1:= i-1 tx:= t1*4 tb := b+tx res:= 0 ix := 0 t0 := lng-1 t11:= i1-1 tx1:= t11*4 ta := a+tx1 t1:= i-1 tx:= t1*4 tb := b+tx if ix<=t0 true false t11:= t11+1 tx1:= tx1+4 ta := ta+4 t := *ta t1:= t1+1 tx:= tx+4 tb := tb+4 t3 := *tb t13:= t*t3 res:= res+t13 ix := ix+1 return res A. Poetzsch-Heffter, TU Kaiserslautern 35 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 75 true ta := ta+4 t := *ta tb := tb+4 t3 := *tb t13:= t*t3 t3 res:= res+t13 ix := ix+1 if ix<=t0 false return res Bewertung: *lng + 1 = 8*lng + 11 ( lng = 100: 811, lng = 1000: 8011 ) Evaluation: * lng +1 = 8 * lng A. Poetzsch-Heffter, TU Kaiserslautern 36 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 76 Potential of s Potential of optimizations - Example (6) Algebraic s: Use invariants ta = 4 (i1 1 + ix) + a for the Algebraische Optimierung: comparison ta 4 (i1 1 + t0) + a Ausnutzen der Invarianten: ta = 4*(i1-1+ix)+ a für den Vergleich: ta <= 4*(i1-1+t0)+ 1+t0)+ a ta := ta+4 t := *ta tb := tb+4 t3 := *tb t13:= t*t3 res:= res+t13 ix := ix+1 skprod: res:= 0 ix := 0 t0 := lng-1 t11:= i1-1 tx1:= t11*4 ta := a+tx1 t1:= i-1 tx:= t1*4 tb := b+tx t4 := t11+t0 t5 := 4*t4 t6 := t5+a if ta<=t6 true false return res A. Poetzsch-Heffter, TU Kaiserslautern 37 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 77 Potential of s Potential of optimizations - Example (7) Dead Code Elimination: Assignment to ix is dead code and can be eliminated. niert werden: skprod: res:= 0 t0 := lng-1 t11:= i1-1 tx1:= t11*4 ta := a+tx1 t1:= i-1 tx:= t1*4 tb := b+tx t4 := t11+t0 t5 := 4*t4 t6 := t5+a if ta<=t6 t6 true false ta := ta+4 t := *ta tb := tb+4 t3 := *tb t13:= t*t3 res:= res+t13 Evaluation: * Ing +1 = 7 * lng + 13 return res c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 78 Potential of s Potential of optimizations - 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 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 79 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 80

11 Liveness 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 Definition (Liveness Analysis) Let P be a program. A variable v is live at a program position S in P if there is an execution path π from S to a use of v such that there is no definition of v on π. The liveness analysis determines for all positions S in P which variables are live at S. Each analysis has an exact specification which information it provides. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 81 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 8 Liveness analysis () Liveness analysis (3) 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 Idea: In a procedure-local analysis, exactly the global variables are live at the end of the exit block of the procedure. 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 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 83 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 84 Liveness analysis (4) Liveness analysis - Example As the set in(b) is computed from out(b), we have a backward analysis. For B not the exit block of the procedure, out(b) is obtained by out(b) = in(b i ) for all successors B i of B Thus, for a program without loops, in(b) and out(b) are defined for all basic blocks B. Otherwise, we obtain a system of recursive equations. Question: How do we compute out(b)? c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 85 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 86 Data flow equations Ambiguity of solutions - Example Theory: There is always a solution for 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 equations may have several solutions. B0: B1: a := a b := 7 out(b0) = in(b0) in(b1) out(b1) = { in(b0) = gen(b0) (out(b0)\kill(b0)) = {a out(b0) in(b1) = gen(b1) (out(b1)\kill(b1)) = { Thus, out(b0) = in(b0), and hence in(b0) = {a in(b0). Possible Solutions: in(b0) = {a or in(b0) = {a, b c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 87 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 88

12 Computation of smallest fixpoint Further analyses and classes of analyses 1. Compute gen(b), kill(b) for all B.. 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. 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 all 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 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 89 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 90 Further analyses and classes of analyses () Further analyses and classes of analyses (3) 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: For forward analyses, the dependency is the other way round: 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 ) with or out(b) = gen(b) (in(b) \ kill(b)) in(b) = out(b i ) B i pred(b) in(b) = out(b i ) B i pred(b) c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 91 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 9 Further analyses and classes of analyses (4) Further analyses and classes of analyses (5) Overview of classes of analyses: conjunction intersection forward reachable definitions available expressions backward live variables busy expressions 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. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 93 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 94 Non-local program analysis 4..4 We use a points-to analysis to demonstrate: 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. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 95 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 96

13 Points-to analysis Alias Information 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 (1) p.f = x; () y = q.f; (3) q.f = z; p == q: (1) () y = x; (3) q.f = z; p!= q: First Erste two Anweisung statements lässt sich can mit den be anderen switched. beiden vertauschen. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 97 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 98 Elimination of Dynamic Binding Escape Analysis class A { void m(... ) {... class B extends A { void m(... ) { A p; p = new B(); p.m(...) // Aufruf von B::m Call of B::m R m( A p ) { B q; q = new B(); // Kellerverwaltung Can be stored on stack möglich q.f = p; q.g = p.n(); return q.g; c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 99 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 100 A Points-to Analysis for Java A Points-to Analysis for Java () Simplifications and assumptions about underlying language 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 Compound statements 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. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 101 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 10 A Points-to Analysis for Java (3) Points-to graph as abstraction Result of the analysis is a so-called points-to graph having 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. Points-to Graph - Example Beispiel: class Y {... class X { (Points-to-Graph) Y f; void set( Y r ) { this.f = r; static void main() { X p = new X(); // s1 erzeugt o1 Y q = new Y(); // s erzeugt o p.set(q); c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 103 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 104 p o1 this

14 Points-to Graph - Example () Definition of the Points-to Graph 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.) c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 105 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 106 Definition of the Points-to Graph () Edges: Smallest Fixpoint of f : PtGraph Stmt PtGraph with Definition of the Points-to Graph (3) 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 oi Pt(G,r0) resolve(g, m, o i, r 1,..., r n, l) where Pt(G, x) is the points-to set of x in G, resolve(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. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 107 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 001. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 108 Register allocation 4.3 Efficient code has to make good use of the available registers on the target machine: Accessing registers is much faster then accessing memory (the same holds for cache). Register allocation has two aspects: Determine which variables are implemented by registers at which positions. Determine which register implements which variable at which positions (register assignment). c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 109 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 110 Register allocation () Register allocation (3) Goals of register allocation 1. Generate code that requires as little registers as possible. Avoid unnecessary memory accesses, i.e., not only temporaries, but also program variables are implemented by registers. 3. Allocate registers such for variables that are used often (do not use them for variables that are only rarely accessed). 4. Obey programmer s requirements. Outline Algorithm interleaving code generation and register allocation for nested expressions (cf. Goal 1) Algorithm for procedure-local register allocation (cf. Goals and 3) Combination and other aspects c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 111 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 11

15 4.3.1 Auswertungsordnung mit minimalem Registerbedarf Der Algorithmus von Sethi-Ullman ist ein Beispiel für eine integriertes Verfahren zur Registerzuteilung und Codeerzeugung. Eingabe: Auswertungsordnung mit minimalem Registerbedarf Evaluation ordering with minimal registers Der Algorithmus von Sethi-Ullman ist ein Beispiel The algorithmfür byeine Sethiintegriertes and UllmannVerfahren is example zur ofregisterzuteilung an integrated approach forund register Codeerzeugung. allocation and code generation. (cf. Wilhelm, Maurer, Sect , p. 584 ff) Eingabe: Input: Eine Zuweisung mit zusammengesetztem Ausdruck An assignment with a nested expression on the right hand side auf der rechten Seite: Assign ( Var, Exp ) Exp = BinExp Var BinExp ( Exp, Op, Exp ) Var ( Ident ) Eine Zuweisung mit zusammengesetztem Ausdruck auf der rechten Seite: Ausgabe: Assign ( Var, Exp ) Zugehörige Maschinencode bzw. Zwischensprachen- c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 113 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 114 Exp = BinExp Var code mit zugewiesenen Registern. Wir betrachten hier BinExp ( Exp, Op, Exp ) Zwei-Adresscode, d.h. Code mit maximal einem Evaluation ordering Var with minimal ( Ident registers ) () Example: Speicherzugriff: Code Beispiel: generation (Codeerzeugung w/ register mit allocation Registerzuteil.) Ri := M[V] Consider f := Betrachte: (a + M[V] b) (c := f:= (d (a+b)-(c-(d+e)) Ri + (c (d+e)) Ausgabe: Output: Ri := Ri op M[V] Zugehörige Maschinencode bzw. Zwischensprachen- Assume that there Annahme: are two Ri := Zur registers Übersetzung R0 and Ri op Rj stehen R1 available nur zwei forregister the Machine or intermediate language code with assigned registers. translation. zur Verfügung. code mit zugewiesenen Registern. Wir betrachten hier We consider two-address Zwei-Adresscode, i.e., code d.h. withcode one memory mit maximal access ateinemresult of direct (vgl. Wilhelm/Maurer 1.4.1, Seite 584 ff) Ergebnis translation: der direkten Übersetzung: maximum. The machine has r registers represented by R 0,..., R r 1. Beispiel: Speicherzugriff: (Codeerzeugung mit Registerzuteil.) R0 := M[a] Ri := M[V] R0 := R0 + M[b] A. Poetzsch-Heffter, TU Kaiserslautern 346 Betrachte: f:= (a+b)-(c-(d+e))(c (d+e)) R1 := M[d] M[V] := Ri Annahme: Ri Zur := Übersetzung Ri op stehen M[V] nur zwei Register Ri zur := Verfügung. Ri op Rj R1 := R1 + M[e] M[t1] := R1 R1 := M[c] R1 := R1 M[t1] Ergebnis der direkten Übersetzung: R0 := R0 R1 (vgl. Wilhelm/Maurer 1.4.1, Seite 584 ff) M[f] := R0 R0 := M[a] R0 := R0 + M[b] c Prof. Dr. Arnd Poetzsch-Heffter Selected R1 Topics := inm[d] Compiler Construction 115 Ergebnis von Sethi-Ullman: TU R1 := R1 + A. M[e] Poetzsch-Heffter, Kaiserslautern 346 R0 := M[c] M[t1] := R1 R1 := M[d] R1 := M[c] R1 := R1 + M[e] Example: Code generation R1 := R1 w/ register M[t1] allocation () Sethi-Ullmann algorithm R0 := R0 R1 R0 := R0 R1 R1 := M[a] M[f] := R0 R1 := R1 + M[b] Result of Sethi-Ullmann algorithm: R1 := R1 R0 Ergebnis von Sethi-Ullman: M[f] := R1 Goal: Minimize number of registers and number of temporaries. R0 := M[c] R1 := M[d] R1 := R1 + M[e] R0 := R0 R1 R1 := M[a] R1 := R1 + M[b] R1 := R1 R0 M[f] := R1 Besser, weil ein Befehl weniger und keine Zwischen- More efficient, because it uses one instruction less and does not need Speicherung nötig. to store intermediate results A. Poetzsch-Heffter, TU Kaiserslautern 347 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 116 Idea: Generate Besser, code weil for subexpression ein Befehl weniger requiring und more keine registers Zwischenfirst. Speicherung nötig. Procedure: A. Poetzsch-Heffter, TU Kaiserslautern 347 Define function regbed that computes the number of registers needed for an expression Generate code for an expression E = BinExp(L,OP,R); c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 117 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 118 Sethi-Ullmann algorithm () Sethi-Ullmann algorithm (3) We use the following notations: v_reg(e): the set of available registers for the translation of E v_tmp(e): the set of addresses where values can be stored temporarily when translating E cell(e): register/memory cell where the result of E is stored Now, let E be an expression L the left subexpression of E R the right subexpression of E vr abbreviate v_reg(e) We distinguish the following cases: 1. regbed(l) < vr. regbed(l) vr and regbed(r) < vr 3. regbed(l) vr and redbed(r) vr c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 119 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 10

16 Sethi-Ullmann algorithm (4) Sethi-Ullmann algorithm (5) Case 1: regbed(l) < vr Generate code for R using v_reg(e) and v_tmp(e) with result in cell(r) Generate code for L using v_reg(e) \{ cell(r) and v_tmp(e) with result in cell(l) Generate code for the operation cell(l) := cell(l) OP cell(r) Set cell(e) = cell(l) c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 11 Sethi-Ullmann algorithm (6) Case 3: regbed(l) vr and redbed(r) vr Generate code for R using v_reg(e) and v_tmp(e) with result in cell(r) Generate code M[first(v_tmp(E))] := cell(r) Generate code for L using v_reg(e) and rest(v_tmp(e)) with result in cell(l) Generate code for the operation cell(l) := cell(l) OP M[first(v_tmp(E))] Set cell(e) = cell(l) Case : regbed(l) vr and regbed(r) < vr 3. Fall: regbed( L )! vr und regbed( R )! vr Generate code for L using v_reg(e) and v_tmp(e) with result in cell(l) Generiere zunächst Code für R Generate unter Verwendung code for R usingvon v_reg(e) v_reg(e) \{ cell(l) und and v_tmp(e) with result mit inergebnis cell(r) in zelle(r) Generate code for the operation cell(l) := cell(l) OP cell(r) Generiere Code: M[ first(v_tmp(e)) ] := zelle(r) Set cell(e) = cell(l) Generiere Code für L unter Verwendung von v_reg(e) und rest( v_tmp(e) ) mit Ergebnis in zelle(l) c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 1 Generiere Code für die Operation: zelle(l) := zelle(l) OP M[ first(v_tmp(e)) ] Setze zelle(e) = zelle(l) Sethi-Ullmann algorithm (7) Function Die regbed Funktion in MAX regbed notation (in(can MAX-Notation): be realized by S-Attribution): ATT regbed( Exp@ E ) Nat: IF Assign@<_,Var@ E> : 0 BinExp@< Var@ E,_,_> : 1 BinExp@<_,_,Var@ E > : 0 BinExp@< L,_, R > E : IF regbed(l)=regbed(r) THEN regbed(l) + 1 ELSE max( regbed(l), regbed(r) ) ELSE nil // Fall kommt nicht vor c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 13 Example: Sethi-Ullman Algorithm (In ML wäre die Definition von regbed etwas Beispiel: (Ablauf Sethi-Ullman) aufwendiger, da der Kontext von Var-Ausdrücken Betrachte: f:= ((a+b)-(c+d)) (c+d)) * (a-(d+e)) (d+e)) nicht direkt berücksichtigt werden kann.) c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 14 Attribute: v_reg v_tmp 1T regbed A. Poetzsch-Heffter, TU Kaiserslautern 350 Example: Sethi-Ullman Algorithm () zelle Assign Consider f:= (( a + b ) - (c + d)) * (a - (d+e)) Beispiel: (Ablauf Sethi-Ullman) Attributes: Betrachte: f:= ((a+b)-(c+d)) (c+d)) * (a-(d+e)) (d+e)) Attribute: v_reg v_tmp 1T regbed zelle Var f 1T BinExp * (3.) 1 BinExp 1T BinExp (1.) (1.) BinExp 1 BinExp 1 Var 1T BinExp a (.) (1.) (1.) 3 1 T Assign Var a Var Var Var Var Var 1 b 0 c 1 d 0 d 1 e 0 Var f 1 1T BinExp * 3 (3.) c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 15 Example: Sethi-Ullman Algorithm (3) 1 BinExp 1T BinExp (1.) (1.) For formalizing the algorithm, we realize the set of available registers and addresses for storing BinExp temporaries 1 BinExp 1with lists, where Var 1T BinExp the list RL+ of registers 1 is non-empty + 1 a the list AL(.) of addresses is long (1.) enough (1.) the result cell is always a register which is the first in RL, i.e., first(rl) Var Var Var Var Var Var the function a 1 exchange b 0 switches c 1 the d first 0 two elements d 1 of ea list, 0 fst returns the first element of the list, rest returns the tail of the list A. Poetzsch-Heffter, TU Kaiserslautern 351 T A. Poetzsch-Heffter, TU Kaiserslautern 351 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 16 Example: Sethi-Ullman Algorithm (4) In the following, the function expcode for code generation is given in MAX notation (functional). Note: The application of the functions exchange, fst and expcode satisfy their preconditions length(rl) > 1 or length(rl) > 0, resp. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 17 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 18

17 Example: Sethi-Ullman Algorithm (5) FCT expcode( E, RegList RL, AdrList AL ) CodeList: // pre: length(rl)>0 IF Var@<ID> E: [ fst(rl) := M[adr(ID)] ] BinExp@< L,OP,Var@<ID> > E: expcode(l,rl,al) ++ [ fst(rl) := fst(rl) OP M[adr(ID)] ] BinExp@< L,OP,R > E: LET vr == length( RL ) : IF regbed(l) < vr : expcode(r,exchange(rl),al) ++ expcode(l,rst(exchange(rl)),al) ++ [ fst(rl):= fst(rl) OP fst(rst(rl))] regbed(l)>=vr AND regbed(r)<vr : expcode(l,rl,al) ++ expcode(r,rst(rl),al) ++ [ fst(rl):= fst(rl) OP fst(rst(rl))] regbed(l)>=vr AND regbed(r)>=vr : expcode(r,rl,al) ++ [ M[ fst(al) ] := fst(rl) ] ++ expcode(l,rl,rst(al)) ++ [ fst(rl):= fst(rl) OP M[fst(AL)] ] ELSE nil ELSE [] c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 19 Beachte: Remarks: Die Anwendungen der Funktionen Register exchange, Allocation fst by Graph und Coloring The algorithm expcode generates erfüllen jeweils AC ihre which Vorbedingungen is optimal with respect to the number of instructions length(rl) > 1 and bzw. the length(rl) number > 0. Register allocation by graph coloring of temporaries if the expression has no common A. Poetzsch-Heffter, subexpressions. TU Kaiserslautern 353 The algorithm shows the dependency between code generation and register allocation and vice versa. In a procedural implementation, register and address lists can be Register allocation by graph coloring is an algorithm (with many realized by a global stack. variants) for allocation of registers in control flow graphs. Register allocation for CGF with 3AC in SSA form Input: CFG with using temporary variables Output: Structurally the same CFG with registers instead of temporary variables additional instructions for storing intermediate results on the stack, if applicable by Graph Coloring 4.3. by Graph Coloring c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 130 by Graph Coloring Register allocation by graph coloring () Remarks: The SSA representation is not necessary, but simplifies the formulation of the algorithm (e.g.,wilhelm/maurer do not use SSA in Sect. 1.5) It is no restriction that only temporary variables are implemented by registers. We assume that program variables are assigned to temporary variables in a preceding step. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 131 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 13 Life range and interference graph by Graph Coloring by Graph Coloring Register allocation by graph coloring Definition (Life range) The life range of a temporary variable is the set of program positions at which it is alive. Definition (Interference) Two temporary variables interfere if their life ranges have a non-empty intersection. Definition (Interference graph) Let P be a program part/cfg in 3AC/SSA. The interference graph of P is an undirected graph G = (N, E), where N is the set of temporary variables an edge (n 1, n ) is in E iff n 1 and n interfere. Goal: Reduce number of temporary variables with the available registers. Idea: Translate the problem to graph coloring (NP-complete). Color the interference graph, such that neighboring nodes have different colors no more colors are used than available registers c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 133 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 134 by Graph Coloring Register allocation by graph coloring () by Graph Coloring Register allocation by graph coloring (3) General procedure: Try to color the graph as described below. Then: If a coloring is found, terminate. If nodes could not be colored, choose a non-colored node k modify the 3AC program such that the value of k is stored temporarily and is first loaded when it is used try to color the modified program Termination: The procedure terminates, because storing values intermediately reduces life ranges of temporaries and interferences. In practice, two or three iterations are sufficient. Coloring algorithm: Let rn be the number of available registers, i.e., for coloring, maximally rn colors may be used. The coloring algorithm consists of the phases: (a) Simplify with marking (b) Coloring c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 135 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 136

18 by Graph Coloring by Graph Coloring Simplify with marking Coloring Remove iteratively nodes with less than rn neighbors from the graph and push them onto a stack. Case 1: The current simplification steps lead to an empty graph. Continue with the coloring phase. Case : The graph contains only nodes with rn and more than rn neighbors. Choose a suitable node as candidate for storing it temporarily, mark it, push it onto the stack and continue simplification. The nodes are successively popped from the stack and, if possible, colored and put back into the graph. Let k be the popped node. Caseh1: k is not marked. Thus, it has less than rn neighbors. Then, k can be colored with a new color. Case : k is marked. a) the rn or more neighbors have less than rn-1 different colors. Then, color k appropriately. b) there are rn or more colors in the neighborhood. Leave k uncolored. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 137 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 138 by Graph Coloring Example - Graph coloring For simplicity, we only consider one basic block. Beispiel: (Graphfärbung) In the beginning, t0 and t are live. Einfachheitshalber betrachten wir nur einen Basisblock: by Graph Coloring Example - Graph coloring () Interference graph: t1 := a + t0 t3 := t 1 t4 := t1 * t3 t5 := b + t0 t6 := c + t0 t7 := d + t4 t8 := t5 + 8 t9 := t8 t := t6 + 4 t0 := t7 Am Anfang sind t0, t lebendig Am Ende sind t0, t, t9 leb. In the end, t0, t, t9 are Interferenzgraph: alive. c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 139 t0 t Example Fortsetzung - Graph des Beispiels: coloring t3 (3) t4 Vereinfachung: Eliminiere der Reihe nach t1, t3, t, t9, t0, t5, t4, t7, t8, t6 t5 by Graph Coloring t1 Possible Möglich coloring: Färbung (t1, t3, t, t9, t0, t5, t4, t7, t8, t6): t9 Annahme: t4 4 verfügbare Register t0 t A. Poetzsch-Heffter, TU Kaiserslautern 358 t3 t1 t t7 t7 t8 t8 t6 t6 Assumption: 4 available registers Simplification: Remove (in order) t1, t3, t, t9, t0, t5, t4, t7, t8, t6 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 140 by Graph Coloring Example - Graph coloring (4) Remarks: There are several extensions of the algorithm: Elimination of move instructions Specific heuristics for simplification (What is a suitable node?) Consider pre-colored nodes Recommended reading: Appel, Sec t9 Bemerkung: c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 141 Es gibt eine Reihe von Erweiterungen des Verfahrens: by Graph Coloring Further Elimination aspectsvon of Move-Befehlen register allocation Bestimmte Heuristiken bei der Vereinfachung (Was ist ein geeigneter Knoten?) Berücksichtigung vorgefärbter Knoten The introduced algorithms consider subproblems. In practice, there are further aspects that have to be dealt with for register allocation: Interaction with other compiler phases (in particular optimization Lesen and codesie generation) zu Abschnitt 4.3.: Appel: Relation between temporaries and registers Source/intermediate/target Section , S language Number of applications (Is a variable inside an inner loop?) A. Poetzsch-Heffter, TU Kaiserslautern 359 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 14 by Graph Coloring Further aspects of register allocation () Possible global procedure Allocate registers for standard tasks (registers for stack and argument pointers, base registers) Decide which variables and parameters should be stored in registers Evaluate application frequency of temporaries (occurrences in inner loops, distribution of accesses over life range) Use evaluation together with heuristics of register allocation algorithm If applicable, optimize again c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 143 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 144

19 Language Execution Techniques Language Execution Techniques c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 145 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 146 Language Execution Techniques Static (Ahead-of-Time) Compilation Interpretation Language Execution Techniques Compile Time Runtime Runtime Source Code AOT Compiler Machine Code Machine Source Code Interpreter Advantages Disadvantages Advantages Disadvantages Fast execution Platform dependent Compilation step Platform independent No compilation step Slow execution Examples C/C++, Pascal Examples Bash, Javascript (old browsers) c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 147 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 148 Language Execution Techniques Use of Virtual Machine Code (Bytecode) Compile Time Runtime Source Code AOT Compiler Bytecode Virtual Machine 4.4. Advantages Faster execution Platform independent Disadvantages Still slow due to interpretation Compilation step Examples Java, C# c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 149 c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 150 Dynamic (Just-In-Time) Compilation Just-in-time Compilation Runtime Byte/Source Code Virtual Machine/ Interpreter Machine JIT Compiler Machine Code Advantages Disadvantages Fast execution JIT runtime overhead Platform independent Examples Java HotSpot VM,.NET CLR, Mozilla SpiderMonkey c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 151 Just-in-time (dynamic) compilation compiles code during runtime The goal is to improve performance compared to pure interpretation Trade-off between compilation cost and execution time benefit c Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 15