15CS314J – COMPILER DESIGN

UNIT 5
Prepared by:
Dr.R.I.Minu
Associate Professor

Prepared by R I Minu 1
Prepared by R I Minu 2
The Principal Sources of
Optimization

Prepared by R I Minu 3
The Principal Sources of Optimization
• A compiler optimization must preserve the semantics of the original
program.
• Except in very special circumstances, once a programmer chooses and
implements a particular algorithm, the compiler cannot understand
enough about the program to replace it with a substantially different
and more efficient algorithm.
• A compiler knows only how to apply relatively low-level semantic
transformations, using general facts

Prepared by R I Minu 4
Causes of Redundancy
• There are many redundant operations in a typical program.
• Sometimes the redundancy is available at the source level. For
instance, a programmer may find it more direct and convenient to
recalculate some result, leaving it to the compiler to recognize that
only one such calculation is necessary.
• But more often, the redundancy is a side effect of having written the
program in a high-level language

Prepared by R I Minu 5
Prepared by R I Minu 6
Prepared by R I Minu 7
Semantics-Preserving Transformations
• There are a number of ways in which a compiler can improve a
program without changing the function it computes.
• Common-subexpression elimination,
• copy propagation,
• dead-code elimination, and constant folding
• are common examples of such function-preserving (or semantics-
preserving) transformations

Prepared by R I Minu 8
Common-sub expression elimination
• Local common sub expression elimination

Prepared by R I Minu 9
Prepared by R I Minu 10
Copy Propagation
• Block B5 can be further improved by eliminating x, using two new
transformations.
• One concerns assignments of the form u = v called copy statements,
or copies for short
• The idea behind the copy-propagation transformation is to use v for
u, wherever possible after the copy statement u = v.

Prepared by R I Minu 11
Dead-Code Elimination
• A variable is live at a point in a program if its value can be used
subsequently
• otherwise, it is dead at that point.
• A related idea is dead (or useless) code - statements that compute
values that never get used.
• One advantage of copy propagation is that it often turns the copy
statement into dead code

Prepared by R I Minu 12
CodeMotion
• Loops are a very important place for optimizations, especially the
inner loops where programs tend to spend the bulk of their time.
• The running time of a program may be improved if we decrease the
number of instructions in an inner loop, even if we increase the
amount of code outside that loop.
• An important modification that decreases the amount of code in a
loop is code motion

Prepared by R I Minu 13
Induction Variables and Reduction in Strength
• Another important optimization is to find induction variables in loops
and optimize their computation.
• A variable x is said to be an "induction variable“ if there is a positive
or negative constant c such that each time x is assigned, its value
increases by c.
• The transformation of replacing an expensive operation, such as
multiplication, by a cheaper one, such as addition, is known as
strength reduction.

Prepared by R I Minu 14
Prepared by R I Minu 15
Introduction to Data-Flow
Analysis

Prepared by R I Minu 16
Introduction to Data-Flow Analysis
• All the optimizations depend on data-flow analysis.
• "Data-flow analysis" refers to a body of techniques that derive
information about the flow of data along program execution paths.
• For example, one way to implement global common subexpression
elimination
• As another example, if the result of an assignment is not used along
any subsequent execution path, then we can eliminate the
assignment as dead code.

Prepared by R I Minu 17
The Data-Flow Abstraction
• Each execution of an intermediate-code statement transforms an
input state to a new output state.
• The input state is associated with the program point before the
statement
• The output state is associated with the program point after the
statement.

Prepared by R I Minu 18
Possible execution paths
• Within one basic block, the program point after a statement is the
same as the program point before the next statement.
• If there is an edge from block B1 to block B2, then the program point
after the last statement of B1 may be followed immediately by the
program point before the first statement of B2.

Prepared by R I Minu 19
Possible execution paths
Thus, we may define an execution path (or just path) from point p1 to point
pn, to be a sequence of points p1 ,p2, . . . , Pn such that for each i = 1,2, . . . , n
- 1, either
1. pi is the point immediately preceding a statement and pi+1 is the point
immediately following that same statement, or
2. pi is the end of some block and pi+1 is the beginning of a successor
block.

“In general, there is an infinite number of possible execution paths through a

Prepared by R I Minu 20
The Data-Flow Analysis Schema
• In each application of data-flow analysis, we associate with every
program point a data-flow value that represents an abstraction of the
set of all possible program states that can be observed for that point.
• We denote the data-flow values before and after each statements by
IN[S] and OUT[S], respectively.
• The data-flow problem is to find a solution to a set of constraints on
the IN[s]'s and OUT[S]'s, for all statements.
• There are two sets of constraints:
• Those based on the semantics of the statements ( "transfer functions")
• Those based on the flow of control.

Prepared by R I Minu 21
Transfer Functions
• Transfer functions come in two flavors: information may propagate forward
along execution paths, or it may flow backwards up the execution paths
• In a forward-flow problem, the transfer function of a statement s, which
we shall usually denote fS takes the data-flow value before the statement
and produces a new data-flow value after the statement. That is,
OUT[S] = FS(IN[S])
• Conversely, in a backward-flow problem, the transfer function f, for
statement s converts a data-flow value
IN[S] = FS(OUT[S])

Prepared by R I Minu 22
Control-Flow Constraints
• Within a basic block, control flow is simple.
• If a block B consists of statements s1 , s2, . . . , Sn in that order, then
the control-flow value out of si is the same as the control-flow value
into si+1. That is,
IN[Si+1] = OUT[Si], for all i = 1,2,3...n-1
• Control-flow edges between basic blocks create more complex
constraints between the last statement of one basic block and the
first statement of the following block.

Prepared by R I Minu 23
Data-Flow Schemas on Basic Blocks
• We denote the data-flow values immediately before and immediately
after each basic block B by IN[B] and OUT[B],respectively.
• The constraints involving IN[B]and OUT[B] can be derived from those
involving IN[S] and OUT[S] for the various statements s in B as follows.
• Suppose block B consists of statements s1, . . . , sn in that order.
• If s1 is the first statement of basic block B, then
IN[B] = lN[s1],

Prepared by R I Minu 24
Data-Flow Schemas on Basic Blocks
• Similarly, if sn is the last statement of basic block B, then
OUT[B] = OUT[Sn].
• The transfer function of a basic block B, which we denote fB, can be
derived by composing the transfer functions of the statements in the
block.
• That is, let fSi be the transfer function of statement si.
• Then fB = fsn o fs(n-1). . . o fs2 o fs1.
• The relationship between the beginning and end of the block is
OUT[B] = fB(IN[B])
Prepared by R I Minu 25
Data-Flow Schemas on Basic Blocks
• The constraints due to control flow between basic blocks can easily
be rewritten by substituting IN[B] and OUT[B] for lN[s1] and OUT[Sn],
respectively.
• For instance, if data-flow values are information about the sets of
constants that may be assigned to a variable, then we have a forward-
flow problem in which

Prepared by R I Minu 26
Data-Flow Schemas on Basic Blocks
• The data-flow is backwards as we shall soon see in live-variable
analysis, the equations are similar, but with the roles of the IN'S and
OUT'S reversed.

Prepared by R I Minu 27
Reaching Definitions
• "Reaching definitions" is one of the most common, and useful data-
flow schemas.
• Let in a block definition d reaches a point p if there is a path from the
point immediately following d to pi such that d is not “killed“ along
that path.
• We kill a definition of a variable x if there is any other definition of x
anywhere along the path.

Prepared by R I Minu 28
Prepared by R I Minu 29
Transfer Equations for Reaching Definitions
• Consider a statement
d: u=v+w
• This statement "generates" a definition d of variable u and "kills" all
the other definitions in the program that define variable u, while
leaving the remaining incoming definitions unaffected.

Prepared by R I Minu 30
Transfer Equations for Reaching Definitions
• The transfer function of definition d thus can be expressed as

• transfer function of a basic block with two function can be

Prepared by R I Minu 31
Transfer Equations for Reaching Definitions
• Thus a block consisting of any number of statements. Suppose block B
has n statement. The equation can be represented as below:

Prepared by R I Minu 32
Control-Flow Equations
• Consider the set of constraints derived from the control flow between
basic blocks.
• since a definition cannot reach a point unless there is a path along
which it reaches, IN[B] needs to be no larger than the union of the
reaching definitions of all the predecessor blocks

Prepared by R I Minu 33
Prepared by R I Minu 34
Runtime Environments

Prepared by R I Minu 35
Prepared by R I Minu 36