4. Selected Topics in Compiler Construction

(1)

Compilers and Language Processing Tools

Summer Term 2011

Prof. Dr. Arnd Poetzsch-Heffter

Software Technology Group TU Kaiserslautern

c

Prof. Dr. Arnd Poetzsch-Heffter 1

Content of Lecture

1. Introduction

2. Syntax and Type Analysis 2.1Lexical Analysis

2.2Context-Free Syntax Analysis 2.3Context-Dependent Analysis 3. Translation to Target Language

3.1Translation of Imperative Language Constructs 3.2Translation of Object-Oriented Language Constructs 4. Selected Topics in Compiler Construction

4.1Intermediate Languages 4.2Optimization

4.3Register Allocation 4.4Just-in-time Compilation 4.5Further Aspects of Compilation 5. Garbage Collection

6. XML Processing (DOM, SAX, XSLT)

c

Prof. Dr. Arnd Poetzsch-Heffter 2

4. Selected Topics in Compiler Construction

c

Prof. Dr. Arnd Poetzsch-Heffter Selected Topics in Compiler Construction 3

Chapter Outline

4. Selected Topics in Compiler Construction 4.1Intermediate Languages

4.1.1 3-Address Code

4.1.2 Other Intermediate Languages 4.2Optimization

4.2.1 Classical Optimization Techniques 4.2.2 Potential of Optimizations 4.2.3 Data Flow Analysis 4.2.4 Non-local Optimization 4.3Register Allocation

4.3.1 Sethi-Ullman Algorithm

4.3.2 Register Allocation by Graph Coloring 4.4Just-in-time Compilation

4.5Further Aspects of Compilation

c

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):

I simplifies representation

I (but needs more work to integrate tasks)

c

Selected topics in compiler construction (2)

Learning 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

c

Intermediate languages

4.1 Intermediate languages

c

Intermediate languages

•Intermediate languages are used as

I appropriate program representation for certain language implementation tasks

I 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 ...

...

c

(2)

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.

c

Intermediate languages 3-Address Code

4.1.1 3-Address Code

c

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

c

3-address code (2)

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

3AC commands

Syntax Explanation

x := y bop z x : = uop z x:= y

x: variable (global, local, parameter, temporary) y,z: variable or constant

bop: binary operator uop: unary operator goto L

if x cop y goto L

jump or conditional jump to label L cop: comparison operator only procedure-local jumps x:= a[i]

a[i]:= y a one-dimensional array x : = & a

x:= *y

*x := y

a global, local variable or parameter

& a address of a

* dereferencing operator

c

3AC commands (2)

Syntax Explanation

param x call p return y

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

Basic blocks

A sequence of 3AC commands can be uniquely partitioned into basic blocks.

Abasic block Bis 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

Basic blocks (2)

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.

(3)

Example: 3AC and basic blocks

Consider the following C program:

Beispiel: (3AC und Basisblöcke) Wir betrachten den 3AC für ein C-Programm:

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);

skprod(0,1,2);

return 0;

}

3AC mit Basisblockzerlegung für die Prozedur main:

main:

a[0] := 1 a[0] := 1 a[1] := 2 b[0] := 4 b[1] := 5 b[2] := 6 param 0 param 1 param 2 call skprod

28.06.2007 © A. Poetzsch-Heffter, TU Kaiserslautern 296 return 0

c

Example: 3AC and basic blocks (2)

3AC with basic block partitioning for main procedure Beispiel: (3AC und Basisblöcke) Wir betrachten den 3AC für ein C-Programm:

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);

skprod(0,1,2);

return 0;

}

3AC mit Basisblockzerlegung für die Prozedur main:

main:

a[0] := 1 a[0] := 1 a[1] := 2 b[0] := 4 b[1] := 5 b[2] := 6 param 0 param 1 param 2 call skprod

28.06.2007 © A. Poetzsch-Heffter, TU Kaiserslautern 296 return 0

c

Example: 3AC and basic blocks (3)

Procedure skprod:Prozedur skprod mit 3AC und Basisblockzerlegung:

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];

}

skprod:

}

return res;

}

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

return res t1 := t2*t3

res:= es+t1 ix := ix+1

28.06.2007 © A. Poetzsch-Heffter, TU Kaiserslautern 297 c

Example: 3AC and basic blocks (4)

Procedure skprod as 3AC with basic blocks

Prozedur skprod mit 3AC und Basisblockzerlegung:

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];

}

skprod:

} return res;

}

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

return res t1 := t2*t3

res:= es+t1 ix := ix+1

28.06.2007 © A. Poetzsch-Heffter, TU Kaiserslautern 297

c

Intermediate Language Variations

3 AC after elimination of array operations (at above example)

Variation im Rahmen einer Zwischensprache:

3-Adress-Code nach Elimination von Feldoperationen anhand des obigen Beispiels:

skprod:p

res:= 0 ix := 0

t1 := i1+ix tx := t1*4 ta := a+tx

true false

return res t2 := *ta

t1 := i2+ix tx := t1*4 tb := b+tx t3 *tb t3 := *tb t1 := t2*t3 res:= res+t1 ix := ix+1

Characteristics of 3-Address Code

•Control flow is explicit.

•Only elementary operations

•Rearrangement and exchange of commands can be handled relatively easily.

c

Intermediate languages Other Intermediate Languages

4.1.2 Other Intermediate Languages

c

Further Intermediate Languages

We consider

•3AC inStatic Single Assignment (SSA)representation

•Stack Machine Code

c

(4)

Single Static Assignment Form

If a variableais read at a program position, this is auseofa. If a variableais written at a program position, this is adefinitionofa. For optimizations, the relationship between use and definition of variables is important.

In SSA representation, each variable has exactly one definition. Thus, relationship between use and definition in the intermediate language is explicit.

c

Single Static Assignment Form (2)

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 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

Example: SSA

In SSA-Repräsentation besitzt jede Variable genau eine Definition. Dadurch wird der Zusammenhang

ischen An end ng nd Definition in der zwischen Anwendung und Definition in der Zwischensprache explizit, d.h. eine zusätzliche def-use-Verkettung oder use-def-Verkettung wird unnötig.

SSA ist im Wesentlichen eine Verfeinerung von 3AC.

Die Unterscheidung zwischen den Definitionsstellen wird häufig durch Indizierung der Variablen dargestellt wird häufig durch Indizierung der Variablen dargestellt.

Für sequentielle Befehlsfolgen bedeutet das:

• An jeder Definitionsstelle bekommt die Variable einen anderen Index

einen anderen Index.

• An der Anwendungsstelle wird die Variable mit dem Index der letzten Definitionsstelle notiert.

a := x + y Beispiel:

a := x + y

₁ ₀ ₀

b := a – 1

a := y + b b := x * 4 a := a + b

b := a - 1 a := y + b b := x * 4 a := a + b

1 1

2 2

0

0 1

a := a + b a := a + b

₃ ₂ ₂

c

SSA - Join Points of Control Flow

At join points of control flow, an additional mechanism is required:

An Stellen, an denen der Kontrollfluß zusammen- führt bedarf es eines zusätzlichen Mechanismus:

führt, bedarf es eines zusätzlichen Mechanismus:

3 2 2

a := x + y

₁ ₀ ₀

a := a – b

b := a

₃

?

...

Einführung der fiktiven Orakelfunktion“ ! die Einführung der fiktiven „Orakelfunktion ! , die quasi den Wert der Variable im zutreffenden Zweig auswählt:

3 2 2

a := x + y

₁ ₀ ₀

a := a – b

a := ! (a ,a ) b := a

₃⁴ ₄ ¹ ³

...

c

SSA - Join Points of Control Flow (2)

Introduce an "oracle"Φthat selects the value of the variable of the use branch:

An Stellen, an denen der Kontrollfluß zusammen- führt bedarf es eines zusätzlichen Mechanismus:

führt, bedarf es eines zusätzlichen Mechanismus:

3 2 2

a := x + y

₁ ₀ ₀

a := a – b

b := a

₃ ?

...

Einführung der fiktiven Orakelfunktion“

!

die Einführung der fiktiven „Orakelfunktion

!

, die quasi den Wert der Variable im zutreffenden Zweig auswählt:

3 2 2

a := x + y

₁ ₀ ₀

a := a – b

a := ! (a ,a ) b := a

₃⁴ ₄ ¹ ³

...

c

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. 19.1. and 19.2)

•The termsingle static assignmentform 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).

c

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.

c

Stack machine code as intermediate language

Homogeneous scenario for Java:Sprachlich homogenes Szenario bei Java:

C1.java

C2.java jikes C1.class

C2 class

Java ByteCode

C2.java

C3.java javac2

C2.class C3.class

JVM

Sprachlich ggf. inhomogenes Szenario bei .NET:

Programme

Intermediate

C# - C il

prog1.cs prog1.il

verschiedener Hochsprachen

Compiler

prog2.cs prog2.il

prog3.il

CLR Haskell -

Compiler prog3.hs

Java-ByteCode und die MS-Intermediate Language sind Beispiele für Kellermaschinencode, d.h.

Z i h b i d f i L f itk ll

Zwischenergebnisse werden auf einem Laufzeitkeller verwaltet.

c

(5)

Stack machine code as intermediate language (2)

Inhomogeneous scenario for .NET:

Sprachlich homogenes Szenario bei Java:

C1.java

C2.java jikes C1.class

C2 class

Java ByteCode

C2.java

C3.java javac2

C2.class C3.class

JVM

Sprachlich ggf. inhomogenes Szenario bei .NET:

Programme

Intermediate

C# - C il

prog1.cs prog1.il

verschiedener Hochsprachen

Compiler

prog2.cs prog2.il

prog3.il

CLR Haskell -

Compiler prog3.hs

Java-ByteCode und die MS-Intermediate Language sind Beispiele für Kellermaschinencode, d.h.

Z i h b i d f i L f itk ll

Zwischenergebnisse werden auf einem Laufzeitkeller verwaltet.

c

Example: Stack machine code

Beispiel: (Kellermaschinencode)

package beisp;

class Weltklasse extends Superklasse implements BesteBohnen { Qualifikation studieren ( Arbeit schweiss){

return new Qualifikation();

} } }

Compiled from Weltklasse.java

class beisp Weltklasse extends beisp Superklasse 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 7 areturn

Bemerkung:

Weitere Zwischensprachen werden insbesondere auch

Weitere Zwischensprachen werden insbesondere auch im Zusammenhang mit Optimierungen eingesetzt.

c

Example: Stack machine code (2)

Beispiel: (Kellermaschinencode)

package beisp;

class Weltklasse extends Superklasse implements BesteBohnen { Qualifikation studieren ( Arbeit schweiss){

return new Qualifikation();

} } }

Compiled from Weltklasse.java

class beisp Weltklasse extends beisp Superklasse 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 7 areturn

Bemerkung:

Weitere Zwischensprachen werden insbesondere auch

28.06.2007 © A. Poetzsch-Heffter, TU Kaiserslautern 304 Weitere Zwischensprachen werden insbesondere auch im Zusammenhang mit Optimierungen eingesetzt.

c

Optimization

4.2 Optimization

c

Optimization

Optimization refers to improving the code with the following goals:

• Runtime behavior

• Memory consumption

• Size of code

• Energy consumption

c

Optimization

Optimization (2)

We distinguish the following kinds of optimizations:

•machine-independent optimizations

•machine-dependent optimizations (exploit properties of a particular real machine)

and

•local optimizations

•intra-procedural optimizations

•inter-procedural/global optimizations

c

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."

c

Optimization Classical Optimization Techniques

4.2.1 Classical Optimization Techniques

c

(6)

Constant Propagation

If the value of a variable is constant, the variable can be replaced with the constant.

c

Constant Folding

Evaluate all expressions with constants as operands at compile time.

Iteration of Constant Folding and Propagation:

c

Non-local Constant Optimization

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

Copy Propagation

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.

c

Copy Propagation (2)

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.

c

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.

c

Common Subexpression Elimination (2)

Optimization of a basic block is done after transformation to SSA and construction of a DAG:

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.

(7)

Algebraic Optimizations

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.

c

Strength Reduction

Replace expensive operations by more efficient operations (partially machine-dependent).

For example: y: = 2* xcan be replaced by y : = x + x

or by y: = x « 1

c

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.

c

Inline Expansion of Procedure Calls (2)

Remarks:

•Expansion is in general more than text replacement:

c

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.

c

Dead Code Elimination

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

Dead Code Elimination (2)

A typical example for non-reachable and thus, dead code that can be eliminated:

c

Dead Code Elimination (3)

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

(8)

Code motion

Move commands over branching points in the control flow graph such that they end up 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.

c

Move code over branching points

If a sequential computation branches, the branches are less often executed than the sequence.

c

Move code over branching points (2)

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.

c

Partial redundancy elimination

Definition (Partial Redundancy)

An assignment isredundantat a program positions, if it has already been executed on all paths tos.

An expressioneisredundantats, if the value ofehas already been calculated on all paths tos.

An assignment/expression ispartially redundantats, if it is redundant with respect to some execution paths leading tos.

c

Partial redundancy elimination (2)

Example:

c

Partial redundancy elimination (3)

Elimination of partial redundancy:

c

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.

Code motion from loops

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.

(9)

Optimization of loop variables

Variables and expressions that are not changed during the execution of a loop are calledloop 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.

c

Optimization of loop variables (2)

Definition (Loop Variables)

A variableiis calledexplicit loop variableof a loopS, if there is exactly one definition ofiinSof the formi:=i+cwherecis loop invariant.

A variablekis calledderived loop variableof a loopS, if there is exactly one definition ofkinSof the formk:=j∗cork:=j+d wherejis a loop variable andcanddare loop invariant.

c

Induction variable analysis

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, the dependencies between variable definitions have to be precisely understood.

c

Loop unrolling

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,ixis dead at the end of the fragment.

Note, the static computation ofix’s values in the unrolled loop.

c

Loop unrolling (2)

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).

c

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

c

Optimization Potential of Optimizations

4.2.2 Potential of Optimizations

c

Potential of optimizations - Example

Consider procedureskprodfor the evaluation of the optimization techniques:

4.2.2 Optimierungspotential

Am Beispiel der Prozedur skprod demonstrieren

i i i d bi T h ik d d

wir einige der obigen Techniken und das Verbesserungspotential, das durch Optimierungen erzielt werden kann; dabei skizzieren wir auch dessen Bewertung.

k d

skprod:

res:= 0 ix := 0

true false

return res t1 := i1+ix

tx := t1*4 ta := a+tx t2 := *ta t1 := i2+ix t1 : i2+ix tx := t1*4 tb := b+tx t3 := *tb t1 := t2*t3 res:= res+t1 ix := ix+1

Bewertung: Anzahl der Befehlsschritte in Abhängigkeit

28.06.2007 © A. Poetzsch-Heffter, TU Kaiserslautern 322 Bewertung: Anzahl der Befehlsschritte in Abhängigkeit von lng: 2 + 2 + 13*lng + 1 = 13*lng + 5 ( lng = 100: 1305, lng = 1000: 13005 )

Evaluation:

Number of steps depending onlng:

2+2+13∗lng+1=13∗lng+5 lng=100: 1305

lng=1000: 13005

c

(10)

Potential of optimizations - Example (2)

Move computation of loop invariant out of loop:Herausziehen der Berechnung der Schleifeninvariante t0:

skprod:

res:= 0 res:= 0 ix := 0 t0 := lng-1

if i < t0

return res t1 := i1+ix

tx := t1*4 if ix<=t0 true false

ta := a+tx t2 := *ta t1 := i2+ix tx := t1*4 tb := b+tx tb : b+tx t3 := *tb t1 := t2*t3 res:= res+t1 ix := ix+1

Bewertung: 3 + 1 + 12*lng + 1 = 12*lng + 5

g g g

( lng = 100: 1205, lng = 1000: 12005 )

Evaluation: 3+1+12*lng+1 = 12 *lng + 5

c

Potential of optimizations - 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.

Optimierung von Schleifenvariablen (1):

Zunächst gibt es keine abgeleiteten Schleifenvariablen, da t1 und tx mehrere Definitionen besitzen; Einführen von SSA für t1 und tx macht t11, tx1, ta, t12, tx2, tb zu abgeleiteten Schleifenvariablen:

skprod:

res:= 0 res:= 0 ix := 0 t0 := lng-1

if i < t0

return res t11:= i1+ix

tx1:= t11*4 1 if ix<=t0 true false

ta := a+tx1 t2 := *ta t12:= i2+ix tx2:= t12*4 tb := b+tx2 tb : b t t3 := *tb t13:= t2*t3 res:= res+t13 ix := ix+1

Potential of optimizations - Example (4)

Optimization of loop variables(2): Inductive definition of loop variablesOptimierung von Schleifenvariablen (2):

Initialisierung und induktive Definition der S hl if i bl

Schleifenvariablen:

skprod:

res:= 0 res:= 0 ix := 0 t0 := lng-1 t11:= i1-1 tx1:= t11*4 ta := a+tx1 t12:= i2-1 tx2:= t12*4 tb := b+tx2

t11:= t11+1 if ix<=t0

true false

return res t11:= t11+1

tx1:= tx1+4 ta := ta+4 t2 := *ta t12:= t12+1 tx2:= tx2+4 tb := tb+4 t3 := *tb t13:= t2*t3 res:= res+t13

28.06.2007 © A. Poetzsch-Heffter, TU Kaiserslautern 325 res: res+t13

ix := ix+1

c

Potential of optimizations - Example (5)

Dead Code Elimination: t11, tx1, t12, tx2 do not influence the result.Elimination toten Codes:

Die Zuweisungen an t11, tx1, t12, tx2sind toter Code da sie das Ergebnis nicht beeinflussen

skprod:

Code, da sie das Ergebnis nicht beeinflussen.

res:= 0 ix := 0 t0 := lng-1 t11:= i1-1 tx1:= t11*4 tx1: t11 4 ta := a+tx1 t12:= i2-1 tx2:= t12*4 tb := b+tx2

if ix<=t0

true false

return res ta := ta+4

t2 := *ta tb := tb+4 t3 := *tb t13:= t2*t3 t13: t2 t3 res:= res+t13 ix := ix+1

28.06.2007 © A. Poetzsch-Heffter, TU Kaiserslautern 326 Bewertung: 9 + 1 + 8*lng + 1 = 8*lng + 11 ( lng = 100: 811, lng = 1000: 8011 )

Evaluation: 9 + 1 + 8 * lng +1 = 8 * lng +11

c

Potential of optimizations - Example (6)

Algebraic Optimizations: Use invariantsta=4∗(i1−1+ix) +afor the comparisonta≤4∗(i1Algebraische Optimierung:−1+t0) +a

Ausnutzen der Invarianten: ta = 4*(i1-1+ix)+ a für den Vergleich:ta < 4*(i1 1+t0)+ a für den Vergleich: ta <= 4*(i1-1+t0)+ a

skprod:

res:= 0 ix := 0 t0 := lng-1 t11:= i1-1 tx1:= t11*4 tx1: t11 4 ta := a+tx1 t12:= i2-1 tx2:= t12*4 tb := b+tx2 t4 := t11+t0 t5 := 4*t4 t6 := t5+a

ta := ta+4 t2 := *ta

if ta<=t6

true false

return res t2 : ta

tb := tb+4 t3 := *tb t13:= t2*t3 res:= res+t13

c

Potential of optimizations - Example (7)

Dead Code Elimination: Assignment to ix is dead code and can be eliminated.Elimination toten Codes:

Durch die Transformation der Schleifenbedingung ist

di Z i C d d d k

die Zuweisung an ixtoter Code geworden und kann eliminiert werden:

skprod:

res:= 0 t0 := lng-1 t11:= i1-1 tx1:= t11*4 ta := a+tx1 ta := a+tx1 t12:= i2-1 tx2:= t12*4 tb := b+tx2 t4 := t11+t0 t5 := 4*t4 t6 := t5+a if ta<=t6

return res ta := ta+4

t2 := *ta tb := tb+4

if ta< t6

true false

tb : tb+4 t3 := *tb t13:= t2*t3 res:= res+t13

28.06.2007 © A. Poetzsch-Heffter, TU Kaiserslautern 328 Bewertung: 11 + 1 + 7*lng + 1 = 7*lng + 13 ( lng = 100: 713, lng = 1000: 7013 )

Evaluation: 11 + 1 + 7 * Ing +1 = 7 * lng + 13

c

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.

Optimization Data flow analysis

4.2.3 Data flow analysis

(11)

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.

c

Liveness analysis

Definition (Liveness Analysis)

LetPbe a program. A variablevisliveat a program positionSinPif there is an execution pathπfromSto a use ofvsuch that there is no definition ofvonπ.

Theliveness analysisdetermines for all positionsSinPwhich variables are live atS.

c

Liveness analysis (2)

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 programmPcan be represented as a functionlivemapping positions inPto bit vectors, where a bit vector contains an entry for each variable in P. Letibe the index of a variable inP, then it holds that:

live(S)[i] =1 iff v is live at positionS

c

Liveness analysis (3)

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 variablesout(B)at the end of a basic blockBare known, the live variablesin(B)at the beginning ofBare computed by:

in(B) =gen(B)∪(out(B)\kill(B)) where

I gen(B)is the set of variablesvsuch thatvis applied inBwithout a prior definition ofv

I kill(B)is the set of variables that are defined inB

c

Liveness analysis (4)

As the setin(B)is computed fromout(B), we have abackward analysis.

ForBnot the exit block of the procedure,out(B)is obtained by out(B) =[

in(Bi)for all successorsBiofB

Thus, for a program without loops,in(B)andout(B)are defined for all basic blocksB. Otherwise, we obtain a system of recursive equations.

c

Liveness analysis - Example

Question: How do we compute out(B2)?

c

Data flow equations

Theory:

• There is always a solution for equations of theconsidered form.

• There is always a smallest solution that is obtained by an iteration starting from emptyinandoutsets.

Note:The equations may have several solutions.

c

Ambiguity of solutions - Example

a := a B0:

b := 7 B1:

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 hencein(B0) ={a} ∪in(B0).

Possible Solutions:in(B0) ={a}orin(B0) ={a,b}

c

(12)

Computation of smallest fixpoint

1. Computegen(B),kill(B)for allB.

2. Setout(B) =∅for allBexcept for the exit block. For the exit block, out(B)comes from the program context.

3. Whileout(B)orin(B)changes for anyB:

Computein(B)from currentout(B)for allB.

Computeout(B)fromin(B)of its successors.

c

Further analyses and classes of analyses

Many data flow analyses can be described as bit vector problems:

•Reaching definitions: Which definitions reach a positionS?

•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 ofgenandkill

•the direction of the analysis and the equations

c

Further analyses and classes of analyses (2)

For backward analyses, the data flow information at the entry of a basic blockBis obtained from the information at the exit ofB:

in(B) =gen(B)∪(out(B)\kill(B))

Analyses can be distinguished if they consider the conjunction or the intersection of the successor information:

out(B) = [

Bi∈succ(B)

in(Bi)

or

out(B) = \

Bi∈succ(B)

in(Bi)

c

Further analyses and classes of analyses (3)

For forward analyses, the dependency is the other way round:

out(B) =gen(B)∪(in(B)\kill(B)) with

in(B) = [

B_i∈pred(B)

out(Bi)

or

in(B) = \

Bi∈pred(B)

out(Bi)

c

Further analyses and classes of analyses (4)

Overview of classes of analyses:

conjunction intersection forward reachable definitions available expressions backward live variables busy expressions

c

Further analyses and classes of analyses (5)

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 ofabstract interpretation.

c

Optimization Non-Local Program Analysis

4.2.4 Non-Local Program Analysis

Non-local program analysis

We use apoints-toanalysis 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.

(13)

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)

I Can p.f = x cause changes to an object referenced by q?

I Can z = p.f read information that is written by p.f = x?

• Call graph construction

• Resolution of virtual method calls

• Escape analysis

c

Alias Information

Beispiele: (Verwendung von Points-to- Analyseinformation)

Analyseinformation)

(1) p.f = x;

(2) f

A. Nutzen von Alias-Information:

(2) y = q.f;

(3) q.f = z;

p == q: (1)

(2) y = x;

(2) y x;

(3) q.f = z;

p != q: Erste Anweisung lässt sich mit den anderen beiden vertauschen anderen beiden vertauschen.

B. Elimination dynamischer Bindung:

class A { class A {

void m( ... ) { ... } }

class B extends A { void m( ) { } void m( ... ) { ... } }

...

A p;

p.m(...) // Aufruf von B::m

First two statements can be switched.

c

Elimination of Dynamic Binding

Beispiele: (Verwendung von Points-to- Analyseinformation) Analyseinformation)

(1) p.f = x;

(2) f

A. Nutzen von Alias-Information:

(2) y = q.f;

(3) q.f = z;

p == q: (1)

(2) y = x;

(2) y x;

(3) q.f = z;

p != q: Erste Anweisung lässt sich mit den anderen beiden vertauschen anderen beiden vertauschen.

B. Elimination dynamischer Bindung:

class A { class A {

void m( ... ) { ... } }

class B extends A {

void m( ) { }

void m( ... ) { ... } }

...

A p;

p.m(...) // Aufruf von B::mCall of B::m

c

Escape Analysis

C. Escape-Analyse:

R m( A p ) {( p ) { B q;

q = new B(); // Kellerverwaltung möglich q.f = p;

q.g = p.n();

q g p ();

return q.g;

}

Eine Points-to-Analyse für Java:

Vereinfachungen:

• Gesamte Programm ist bekannt.

• Nur Zuweisungen und Methodenaufrufe der folgenden Form:

Di kt Z i

- Direkte Zuweisung: l = r - Schreiben auf Instanzvariablen: l.f = r - Lesen von Instanzvariablen: l = r.f

Objekterzeugung: l C()

- Objekterzeugung: l = new C() - Einfacher Methodenaufruf: l = r0.m(r1,..)

• Ausdrücke ohne Seiteneffekte

• Zusammengesetzte Anweisungen

Can be stored on stack

c

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:

I Direct assignment:^{l = r}

I Write to instance variables:l.f = r I Read of instance variables:l = r.f I Object creation:l = new C() I Simple method call:l = r0.m(r1, ...)

• Expressions without side effects

• Compound statements

c

A Points-to Analysis for Java (2)

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

A Points-to Analysis for Java (3)

Points-to graph as abstraction

Result of the analysis is a so-calledpoints-to graphhaving

• abstract variablesandabstract objectsas nodes

• edges represent that anabstract variablemay have areference 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.

c

Points-to Graph - Example Beispiel: (Points-to-Graph)

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“ o2q (); // „ g p.set(q);

} }

p

o1 this

o1

f q

r

o2

r

c