Optimization ד " ר בלהה מנדלסון [email protected].

Optimization

ד"ר בלהה מנדלסון

[email protected]

אופטימיזציה

בספר10 ו-9חלקים מפרקים Compilers Principles, Techniques

and Tools – Aho, Sethi and Ullman

code optimization

syntax analysis

semantic analysis

intermediate code optimization

code generation

syntax tree

intermediate code

intermediate code

registers;instruction selection ;

peephole

data flow analysis

User (through source code)

compiler

compiler

optimizerמבנה ה-

control flow analysis

data flow analysis

intermediate code optimization

intermediate code

intermediate code

intermediate code

intermediate code

אופטימיזציה

שימור נכונות הקוד השגת שיפור ניכר בזמן ריצה )לעיתים זמן

הריצה גדל(יעילות סבירה הערה – ככל ששפת התכנות גבוהה יותר, קל

יותר לבצע אופטימיזציה הערה – המדובר הוא בשיפור הקוד, לא

באופטימיזציה במובן המתמטי

אופטימיזציה הקוד המוצר על ידי שיפור אופטימיזציה היא תהליך של

הקומפילר הקוד יכול להיות בצורת קוד ביניים - מבצעים אופטימיזציות שאינן

( machine independent optimizationתלויות במכונה )/הקוד יכול להיות בצורת קוד מכונהassembly מבצעים -

machine dependentאופטימיזציות תלויות במכונה )optimization )

השם אופטימיזציה מטעה משום שהקוד הנוצר הוא לעיתים רחוקותאופטימאלי. לרוב הוא יותר טוב מהקוד ללא הפעלת השיפורים

סוגים שונים של אופטימיזציות אפשריות )פשוטותומסובכות(

נתחיל באופטימיזציות שאינן תלויות במכונה

Algebraic Improvements

אופטימיזציות פשוטות: מטפלות בביטוייםאלגברים

לדוגמא x + 0 = 0 + x = x x - 0 = x x * 1 = 1 * x = x x / 1 = x x ** 2 = x * x x * 2 = 2 * x = x + x x / 2 = x * 0.5

Non-Algebraic Optimizations

אופטימיזציות נוספות דורשות אנליזה נוספתשל התכנית

אנליזה אחת היא חלוקת התכנית לקבוצות של basic blocksבלוקים הבסיסיים

האופטימיזציות מתבצעות בתוך ובין הבלוקיםהבסיסיים

Basic Blocks -קביעת הבלוקים הבסיסיים נעשית על ידי בחירת ה

leadersהפקודות הראשונות בבלוקים הבסיסיים – הפקודה הראשונה היאleader כל פקודה שהיא יעד )של קפיצה מותנת ולא-מותנת( היא

leader )כל פקודה המופיעה לאחר קפיצה )מותנת ולא-מותנת

leaderהיא -בלוק בסיסי מתחיל בleader שלו ומכיל את כל

הבאleaderהפקודות עד אבל לא כולל את ה-

Basic Blocks - example

(1) PROD:=0(2) i:=1(3) T1:=4*I(4) T2:=a[t1](5) T3:=4*I(6) T4:=b[t3](7) T5:=t2*t4(8) T6:=prod+t5(9) Prod:=t6(10)t7:=i+1(11)i:=t7(12)If i<20 goto (3)(13)L: …..

(1) PROD:=0(2) i:=1(3) T1:=4*I(4) T2:=a[t1](5) T3:=4*I(6) T4:=b[t3](7) T5:=t2*t4(8) T6:=prod+t5(9) Prod:=t6(10)t7:=i+1(11)i:=t7(12)If i<20 goto (3)(13)L: …..

BB1

BB2

BB3

Non-Algebraic Optimizations

אופטימיזציות אשר יכולות להתבצע בתוךהבלוקים הבסיסיים:

common sub-expression eliminationdead code eliminationstatement interchangereduction in strength

אופטימיזציות אשר יכולות להתבצע בין הבלוקיםהבסיסיים:

common sub-expression eliminationcopy propogationdead code elimination

Control Flow Graph:בלוקים בסיסיים צמתים :קשתות

אם הפקודה האחרונה בבלוק הבסיסי איננהקפיצה: צור קשת לבלוק הבא

אם הפקודה האחרונה בבלוק הבסיסי היאצור קשת לבלוק אליו קפיצה בלתי מותנת:

הופנתה הקפיצה אם הפקודה האחרונה בבלוק הבסיסי היא

צור קשתות לשני יעדי הקפיצה קפיצה מותנת:

Control Flow Graph

Basic Block Optimizations

-שימוש בnext use עבור כל משתנהקבוע וזמני שמשתמשים בו בבלוק הבסיסי

השימוש הבא של משתנה בבלוק הבסיסמתיחס לפקודה הבאה שם יש התייחסות

למשתנה )כל עוד מחזיק את הערך המסוים(

A := B+CD:=A*2A:=E/F


-החישוב של הnext use מתבצע על ידי סריקה לאחור של הפקודות בבלוק הבסיסי:

1. Upon encountering the statement ‘(i) X := Y op Z’ during the backward scan we do the following:

2. Attach to statement ‘i’ the current information regarding next-uses of ‘X’, ‘Y’, and ‘Z’

3. Set the information for ‘X’ to indicate no next use4. Set the information for ‘Y’ and ‘Z’ to indicate that the

next use is in statement ‘i’



ניתן לקבוע את ההגדרה עבור כל הופעתמשתנה

איזה פקודה בבלוק הבסיס קובעת את ערךהמשתנה אשר משתמשים בו בפקודה מסוימת

-מתיחסים לרוב בdef-use (DU) chains and use-def (UD) chains

שרשרתuse-def מתיחסת לשימושים של ההגדרות של המשתנה


Consider common sub-expression elimination the idea is to recognize that two statements in

the basic block compute the same expression and to avoid the recomputation by saving the value computed in a temporary and then re-using it later

So how do we know when two sub-expressions are the same (i.e. “common”)? If the RHS operands are the same then the sub-

expressions may be the same They are the same as long as the instances of

the operands are the same


Whether or not the instances of a variable are the same depends on whether or not they are from the same definition

If we have information relating each use to its definition (e.g. UD chains) then this is easy to determine

Consider: a := b + c is a := b + c b := a - d equivalent b := a - d c := b + c to c := b + c d := a - d d := b


At the same time we compute next use information we can also compute liveness information

A variable is live if it will be used later in the program When we encounter the statement ‘(i) X := Y op Z

during the scan, we record the liveness information for ‘X’, ‘Y’, and ‘Z’ and then we mark ‘X’ dead and we mark ‘Y’ and ‘Z’ live

If after doing this, we find a statement ‘(i) X := Y op Z in the basic block where ‘X’ is dead we may safely remove the statement from the basic block

Programmer defined variables may be used in later blocks so at this point, we only apply this when ‘X’ is a temporary not maintained across basic blocks


Statement interchange and reduction in strength do depend on next use information

Two statements X := b + c Y := e + f may be interchanged only if neither ‘e’ nor ‘f’ is

‘X’ and if neither ‘b’ nor ‘c’ is ‘Y’ Strength reduction is the replacement of

computations using expensive operations using cheaper ones

Code Generation Revisited

Preserving useful values in registers is important in ensuring efficient code

Previously, the best we could do was try to keep the values of sub-expressions from within a single expression in registers

With definition/use information in a basic block we have the basis of the information we need in order to preserve register values across the statements within a basic block This may lead to significant savings in loads

and stores we don’t have to generate

Finding Loops in the CFG

Optimizing code in loops (and the loops themselves) is an important step in code improvement

To be able to do this, we must be able to detect loops in the control flow graph In some languages loops are not explicit in

the source code E.g. implementation via unstructured GOTOs, etc

Certain loops may be difficult to optimize and we are less interested in these loops

It is safer to detect the loops we are interested in from the intermediate form


The detection of loops in a CFG is based on the concept of domination (between nodes in the CFG)

A node ‘D’ dominates another node ‘N’ if every path from the initial node in the graph to ‘N’ goes through ‘D’ (we write ‘D dom N’ to indicate this fact)

There are some special cases we should consider The initial node in the flow graph dominates all others A node always dominates itself

The dominator information for a flow graph may be represented as a dominator tree where each node in the tree dominates the nodes beneath it

Such a construction is always possible



Loops of interest for optimization purposes are those which:

have a single entry point referred to as the header have at least one path back to the header

Any edge whose head dominates its tail is referred to as a back edge (i.e. an edge N -> D)

Back edges in the flow graph provide the path from the end of a loop back to its header

The natural loop corresponding to a back edge ‘N->D’ consists of ‘D’ and all those flow graph nodes which can reach ‘N’ without going through ‘D’.

inner loops are also easy to find (unless they share a header with an outer loop)

Global Dataflow Analysis

Having the CFG and information related to loops, we can now attempt optimization across basic blocks

Such optimizations must be concerned with the flow of data from one basic block to another

Consider common sub-expressions where we must know all the paths between two candidate sub-expressions in order to determine whether or not the sub-expressions are really common

Such analysis is called global dataflow analysis ‘global’ since it is applied between basic blocks ‘dataflow analysis’ since the flow of data is being

analyzed

Global Dataflow Analysis

Dataflow analysis is computing and propogating information about the use or values of data throughout the basic blocks of a program

This is normally done by defining, and then solving, sets of equations of the form:

out[BB] = gen[BB] (in[BB] - kill[BB]) such an equation determines the information flowing

out of basic block ‘BB’ (or a statement) to be either information generated in the basic block or information flowing into the basic block which is not “killed” within the basic block

There are numerous variations on this general equation

Reaching Definitions reaching definitions: a data flow problem

The problem is to determine the set of definitions of (i.e. assignments to) a variable that may reach a particular use of (i.e. reference to) that variable (hence, “reaching definitions”)

A definition ‘d’ reaches a point ‘p’ (normally a statement containing a use of the variable defined) in a flow graph if there is a path from ‘d’ to ‘p’ such that ‘d’ is not killed (i.e. the variable is not redefined) along that path

An unambiguous definition ‘d’ always sets the value of the variable being defined

Reaching Definitions Ambiguous definitions are also a possibility but

we ignore them e.g. assignments through a pointer that may refer to a

variable This illustrates an important concept in dataflow

analysis; “We must always make conservative assumptions!”

Since our information is imperfect (run time values cannot be known at compile time) we must assume worst case assumptions

e.g. if we are interested in knowing which definitions may reach a use, an ambiguous definition must not kill a previous definition

Reaching Definitions Dataflow analysis is easier in programs which

are compiled from languages supporting only structured control flow constructs

i.e. constructs with a single entry point and exit point Unstructured constructs makes the

determination of how information flows from basic block to basic block difficult

We will focus only on dataflow analysis of structured programs

We can thus easily construct rules for propogating dataflow information based on the type of construct encountered

Reaching Definitions

Reaching Definitions We can apply these rules iteratively to

compute the needed reaching definitions information

The iteration is needed because of the presence of loops

Effectively, we continue re-calculating the outs and ins until the system stabilizes i.e. we reach a fixpoint in the computation

A simple and efficient representation of sets uses bit strings for reaching definitions, we will have one bit per

definition


Reaching Definitions - Algorithm


Use of Reaching Definitions

A use of reaching definition information is in the determination of next uses and liveness information between basic blocks

This information may be used to improve register usage (aka global register

allocation) Can be applied to certain other optimizations In particular, constant propogation depends

on the fact that at a given use of some variable we can verify that all definitions of that variable set it to some constant value

Use of Reaching Definitions

If we have a statement A:=X+B and we are interested in knowing if X can be replaced by a constant value (i.e. constant propogation)

We must consider all paths from the program’s start to the assignment and ensure that along each possible path there is at least one assignment to X and the last assignment on each path sets X to the same constant value

This may be an iterative process

Other Dataflow Problems - Available

Expressions

The goal is to determine which simple expressions are “available” at a given point so that we may use the value of those expressions rather than re-computing them (i.e. common sub-expressions across basic blocks)


Expressions An expression ‘X op Y’ is available at a point ‘p’ if

every path from the initial node to ‘p’ evaluates ‘X op Y’ and there are no subsequent assignments to ‘X’ or ‘Y’ before the point ‘p’

If, at the point ‘p’, we have code to evaluate ‘X op Y’ and assign it to ‘Z’ then we can replace it with a simple assignment of the value of ‘X op Y’ to ‘Z’

Of course, this implies that we must save that value in a known temporary at each relevant definition point so that we know where to get the value

Since the evaluations of ‘X op Y’ may yield values which are assigned to different LHSs on different paths


Expressions A block kills an available expression ‘X op Y’ if it

reassigns to either ‘X’ or ‘Y’ and does not subsequently re-compute ‘X op Y’

A block generates an available expression ‘X op Y’ if it definitely computes ‘X op Y’ without subsequently assigning to ‘X’ or ‘Y’

The dataflow equations for available expressions are:

out[B] = in[B] - kill[B] È gen[B] in[B] = Ç out[p], ‘p’ a predecessor of ‘B’ in[B1]= empty set

Notice that we are using intersection rather than union

This is important


Expressions The use of the intersection operator

guarantees that a given expression is not propagated to the next basic block unless it is available at all of its predecessors

This is what we want - its the definition of an available expression

The use of intersection vs. union is only one example of how the dataflow equations may be changed

Other Dataflow Problems - live variable

analysis A variable ‘X’ is live at some point ‘p’ if there is

some path from ‘p’ along which thevalue of ‘X’ may be used before redefinition

Otherwise, ‘X’ is said to be dead Live variable analysis may be used to do dead

code elimination and to decrease the cost of saving register values on exit from a basic block

What we want to do for live variable analysis between basic blocks is very similar to what we did within basic blocks

i.e. we will perform a backwards scan and associate uses with their preceding definitions (no subsequent use means a definition is dead)


analysis In dataflow analysis for live variables, we

propagate definitions to their preceding uses according to the control flow reflected in the CFG

‘in(B)’ is the set of variables whose values are live at the beginning of basic block ‘B’ and ‘out(B)’ is the set of variables whose values are live at the end of ‘B’

This means that we will compute the ‘in’s in terms of the ‘out’s as illustrated in the following:

in(B) = (out(B)-kill(B)) È gen(B) out(B) = È in(S), ‘S’ a successor of ‘B’


analysis The specification of ‘gen’ and ‘kill’ assume that it is

safe to assume that a variable is live but not safe to assume it is dead

its “conservative” - we save if we don’t know for sure that we don’t have to

Due to the backwards flow of data, when we solve the dataflow equations iteratively, we must check for stability in the ‘in’s not in the ‘out’s

Dataflow analysis may also be used to determine reached uses rather than reaching definitions

together they permit the construction of UD and DU chains

Other Global Optimizations

code motion and induction variables These are optimizations applied to loops which

therefore also cross basic block boundaries The detection of loop invariant computations

which should be moved out of the loop (via code motion) is done using UD (Use-Definition) chains

If we have the statement ‘X:=Y op Z’ within the body of the loop (as determined by dominator information) and if all possible definitions of ‘Y’ and ‘Z’ are outside the loop (as judged by the UD chains for ‘Y’ and ‘Z’) then the statement is loop-invariant

Other Global Optimizations code

motion When doing code motion to remove invariant

expressions, we create a pre-header node for the loop which has a single outgoing edge leading to the header node for the loop and has an incoming edge for each CFG edge that previously pointed to the header

All loop-invariant computations are factored out into the pre-header node

because these computations may depend on one another, their order is maintained between the loop and the pre-header for the loop

Note: code motion affects existing dataflow information

Other Global Optimizations induction

variables The elimination of unnecessary induction variables is a

tricky but useful optimization Induction variables arise both due to programmer

specifications and due to code generated by the compiler to support access to arrays within loops

An induction variable is any variable in a loop which is incremented (or decremented) by a constant value for each loop iteration

To eliminate unnecessary induction variables we must be able to detect them

We begin by looking for basic induction variables A basic induction variable is one which is calculated from the

loop variable ‘i’ by a simple addition or subtraction of a constant

Other Global Optimizations induction

variables We then look for other induction variables

which are a linear function of any of the basic induction variables i.e. code like ‘j:=i*a+b’

Each basic induction variable and the induction variables which are linear functions of it form a family of induction variables

We can choose an induction variable from each family that is simple to compute and replace all references to others with appropriate (strength reduced) code

Other Global Optimizations

Certain high level language features hinder the process of optimization

We have already seen that unstructured control flow can make the optimization of loops difficult

irregular control flow also complicates the computation of dataflow information by producing so-called “irreducible” flow graphs for which many optimizations cannot be applied

Aliasing Dataflow analysis depends on our being able to track the

flow of data in a program When a language supports pointers or certain other

features (such as FORTRAN COMMON blocks) this is hard to do

Hindrances to Optimization

Such language features introduce aliases for variables

i.e. alternate names by which they may be referred to In the presence of aliasing it may be difficult to

accurately determine when a particular piece of data is being referenced or assigned to

e.g. what does this pointer point at?

The analysis required to support between program procedures optimization is known as inter-procedural analysis

Hindrances to Optimization

The motivation for doing interprocedural analysis is the fact that when a subroutine is called within a basic block we must make conservative assumptions about what will be accessed (i.e. everything) and this is very inefficient

The basic block may be within a loop (or loops) The analysis need for inter-procedural optimizations is

basically similar to dataflow analysis The real problem comes in due to the size of the

program which we are trying to optimize Virtually all optimization problems are computationally

expensive and as soon as we try to consider an entire program things get much more difficult

Things like register management are more difficult because we are trying to do still more with such limited resources

Peephole optimization Peephole optimization may be

applied to either intermediate form code or to machine code

We will examine it in the context of machine code and thereby discuss machine dependent optimizations

void quicksort ( m , n )int m , n ; {

i = m – 1 ; j = n ; v = a [ n ];while (1) {

int i , j ;int v , x ;if ( n <= m ) return ; code fragmentquicksort ( m , j ) ; quicksort ( i + 1 , n ) ; }

do i = i + 1 ; while ( a [ i ] < v ) ; do j = j – 1 ; while ( a [ j ] > v ) ;if ( i >= j ) break ; x = a [ i ] ; a [ i ] = a [ j ] ; a [ j ] = x ; }x = a [ i ] ; a [ i ] = a [ n ] ; a [ n ] = x ;

(1)(2)(3)(4)(5)(6)(7)(8)(9)

(10)(11)(12)(13)(14)(15)

i := m – 1j : = nt1 := 4 nv := a [ t1 ]i := i +1t2 := 4 it3 := a [ t2 ]if t3 < v goto (5)j := j – 1t4 := 4 jt5 := a [ t4 ]if t5 > v goto (9)if i >= j goto (23)t6 := 4 ix := a [ t6 ]

(16)(17)(18)(19)(20)(21)(22)(23)(24)(25)(26)(27)(28)(29)(30)

t7 := 4 it8 := 4 jt9 := a [ t8 ]a [ t7 ] := t9

t10 := 4 ja [ t10 ] := xgoto (5)t11 := 4 ix := a [ t11 ]t12 := 4 it13 := 4 nt14 := a [ t13 ]a [ t12 ] := t14

t15 := 4 na [ t15 ] := x

void quicksort ( m , n )int m , n ; {

i = m – 1 ; j = n ; v = a [ n ];while (1) {

int i , j ;int v , x ;if ( n <= m ) return ; code fragmentquicksort ( m , j ) ; quicksort ( i + 1 , n ) ; }

do i = i + 1 ; while ( a [ i ] < v ) ; do j = j – 1 ; while ( a [ j ] > v ) ;if ( i >= j ) break ; x = a [ i ] ; a [ i ] = a [ j ] ; a [ j ] = x ; }x = a [ i ] ; a [ i ] = a [ n ] ; a [ n ] = x ;

(1)(2)(3)(4)(5)(6)(7)(8)(9)

(10)(11)(12)(13)(14)(15)

i := m – 1j : = nt1 := 4 nv := a [ t1 ]i := i + 1t2 := 4 it3 := a [ t2 ]if t3 < v goto (5)j := j – 1t4 := 4 jt5 := a [ t4 ]if t5 > v goto (9)if i >= j goto (23)t6 := 4 ix := a [ t6 ]

(16)(17)(18)(19)(20)(21)(22)(23)(24)(25)(26)(27)(28)(29)(30)

t7 := 4 it8 := 4 jt9 := a [ t8 ]a [ t7 ] := t9

t10 := 4 ja [ t10 ] := xgoto (5)t11 := 4 ix := a [ t11 ]t12 := 4 it13 := 4 nt14 := a [ t13 ]a [ t12 ] := t14

t15 := 4 na [ t15 ] := x

B1

B2

B4

B5

B6

B3

t11 := 4 ix := a [ t11 ]t12 := 4 it13 := 4 nt14 := a [ t13 ]a [ t12 ] := t14

t15 := 4 na [ t15 ] := x

t6 := 4 ix := a [ t6 ]t7 := 4 it8 := 4 jt9 := a [ t8 ]a [ t7 ] := t9

t10 := 4 ja [ t10 ] := xgoto B2

if i >= j goto B6

j := j – 1t4 := 4 jt5 := a [ t4 ]if t5 > v goto B3

i := i + 1t2 := 4 it3 := a [ t2 ]if t3 < v goto B2

i := m – 1j : = nt1 := 4 nv := a [ t1 ]

שלב א'

ביטול ביטויים משותפים באופן גלובלי


t15 := 4 na [ t15 ] := x


t10 := 4 ja [ t10 ] := xgoto B2

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

שלב א'


t4


t15 := 4 na [ t15 ] := x


t10 := 4 ja [ t10 ] := xgoto B2

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

שלב א'


t4

t4


t15 := 4 na [ t15 ] := x


t10 := 4 ja [ t10 ] := xgoto B2

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

שלב א'


t4

t4

t5


t15 := 4 na [ t15 ] := x


t10 := 4 ja [ t10 ] := xgoto B2

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

שלב א'


t4

t4

t5

t2


t15 := 4 na [ t15 ] := x


t10 := 4 ja [ t10 ] := xgoto B2

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

שלב א'


t4

t4

t5

t2

t2


t15 := 4 na [ t15 ] := x


t10 := 4 ja [ t10 ] := xgoto B2

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

שלב א'


t4

t4

t5

t2

t2

t3


t15 := 4 na [ t15 ] := x


t10 := 4 ja [ t10 ] := xgoto B2

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

שלב א'


t4

t4

t5

t2

t2

t3

t2


t15 := 4 na [ t15 ] := x


t10 := 4 ja [ t10 ] := xgoto B2

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

שלב א'


t4

t4

t5

t2

t2

t3

t2

t2


t15 := 4 na [ t15 ] := x


t10 := 4 ja [ t10 ] := xgoto B2

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

שלב א'


t4

t4

t5

t2

t2

t3

t2

t2

t3


t15 := 4 na [ t15 ] := x


t10 := 4 ja [ t10 ] := xgoto B2

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

שלב א'


t4

t4

t5

t2

t2

t3

t2

t2

t3

t1


t15 := 4 na [ t15 ] := x


t10 := 4 ja [ t10 ] := xgoto B2

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

שלב א'


t4

t4

t5

t2

t2

t3

t2

t2

t3

t1

t1


t15 := 4 na [ t15 ] := x


t10 := 4 ja [ t10 ] := xgoto B2

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

שלב א'


t4

t4

t5

t2

t2

t3

t2

t2

t3

t1

t1

x := t3

t14 := a [ t1 ]a [ t2 ] := t14

a [ t1 ] := x

x := t3

a [ t2 ] := t5

a [ t4 ] := xgoto B2

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

ביטול ביטויים משותפים באופן שלב א' -- גלובלי

f := g)אם copy propagationשלב ב' -- (f ולהפטר מ- gננסה לעשות שימוש ב-

x := t3

t14 := a [ t1 ]a [ t2 ] := t14

a [ t1 ] := x

x := t3

a [ t2 ] := t5


t3

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

ביטול ביטויים משותפים באופן –שלב א' גלובלי

copy propagation –שלב ב'

)מציאת dead code elimination שלב ג' –משפטים שאין בתוצאתם שימוש בהמשך(

x := t3

t14 := a [ t1 ]a [ t2 ] := t14

a [ t1 ] := x

x := t3

a [ t2 ] := t5


t3

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]



)מציאת dead code elimination שלב ג' –משפטים שאין בתוצאתם שימוש בהמשך(

x := t3

t14 := a [ t1 ]a [ t2 ] := t14

a [ t1 ] := x

x := t3

a [ t2 ] := t5


t3

t3

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

x := t3

t14 := a [ t1 ]a [ t2 ] := t14

a [ t1 ] := x

x := t3

a [ t2 ] := t5


t3



dead code elimination שלב ג' –

)הוצאת ביטויים code motion – שלב ד'מחוץ ללולאה(

t3

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

x := t3

t14 := a [ t1 ]a [ t2 ] := t14

a [ t1 ] := x

x := t3

a [ t2 ] := t5


t3




code motion – שלב ד'

induction variables and שלב ה' –reduction in strength זיהוי המשתנים של(

הלולאה(

t4 := t4 – 4

t4 := 4 j

t3

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

x := t3

t14 := a [ t1 ]a [ t2 ] := t14

a [ t1 ] := x

x := t3

a [ t2 ] := t5


t3






הלולאה(

t4 := t4 – 4

t2 := t2 + 4

t4 := 4 jt2 := 4 i

t4 := 4 j

t3

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

x := t3

t14 := a [ t1 ]a [ t2 ] := t14

a [ t1 ] := x

x := t3

a [ t2 ] := t5


t3






הלולאה(

t4 := t4 – 4

t2 := t2 + 4

t4 := 4 jt2 := 4 i

t2 >= t4

t3

t14 := a [ t1 ]a [ t2 ] := t14

a [ t1 ] := t3

a [ t2 ] := t5

a [ t4 ] := t3

goto B2

if t2 >= t45 goto B6

t4 := t4 – 1t5 := a [ t4 ]if t5 > v goto B3

t2 := t2 + 4t3 := a [ t2 ]if t3 < v goto B2

i := m – 1j : = nt1 := 4 nv := a [ t1 ]t4 := 4 jt2 := 4 i


t15 := 4 na [ t15 ] := x


t10 := 4 ja [ t10 ] := xgoto B2

if i >= j goto B6



i := m – 1j : = nt1 := 4 nv := a [ t1 ]

Optimization ד " ר בלהה מנדלסון [email protected].

Documents