UNIT-V

CONTROL /DATA FLOW ANALYSIS:

FLOW GRAPHS :

We can add flow control information to the set of basic blocks making up a program by
constructing a directed graph called a flow graph. The nodes of a flow graph are the basic nodes.
One node is distinguished as initial; it is the block whose leader is the first statement. There is a
directed edge from block B1 to block B2 if B2 can immediately follow B1 in some execution
sequence; that is, if

- There is conditional or unconditional jump from the last statement of B1 to the first
statement of B2 , or
- B2 immediately follows B1 in the order of the program, and B1 does not end in an
unconditional jump. We say that B1 is the predecessor of B 2,and B 2 is a successor of B1.

For register and temporary allocation

- Remove variables from registers if not used

- Statement X = Y op Z defines X and uses Y and Z
- Scan each basic blocks backwards
- Assume all temporaries are dead on exit and all user variables are live on exit

The use of a name in a three-address statement is defined as follows. Suppose three-

address statement i assigns a value to x. If statement j has x as an operand, and control can flow
from statement i to j along a path that has no intervening assignments to x, then we say statement
j uses the value of x computed at i.

We wish to determine for each three-address statement x := y op z, what the next uses of
x, y and z are. We collect next-use information about names in basic blocks. If the name in a
register is no longer needed, then the register can be assigned to some other name. This idea of
keeping a name in storage only if it will be used subsequently can be applied in a number of
contexts. It is used to assign space for attribute values.

The simple code generator applies it to register assignment. Our algorithm is to determine
next uses makes a backward pass over each basic block, recording (in the symbol table) for each
name x whether x has a next use in the block and if not, whether it is live on exit from that block.
We can assume that all non-temporary variables are live on exit and all temporary variables are
dead on exit.

Algorithm to compute next use information

- Suppose we are scanning i : X := Y op Z in backward scan

 - Attach to i, information in symbol table about X, Y, Z
- Set X to not live and no next use in symbol table
- Set Y and Z to be live and next use in i in symbol table

As an application, we consider the assignment of storage for temporary names. Suppose we

reach three-address statement i: x := y op z in our backward scan. We then do the following:

1. Attach to statement i the information currently found in the symbol table regarding the
next use and live ness of x, y and z.

2. In the symbol table, set x to "not live" and "no next use".

3. In the symbol table, set y and z to "live" and the next uses of y and z to i. Note that the
order of steps (2) and (3) may not be interchanged because x may be y or z.

If three-address statement i is of the form x := y or x := op y, the steps are the same as above,
ignoring z. consider the below example:

1: t1 = a * a
2: t 2 = a * b
3: t3 = 2 * t2
4: t4 = t 1 + t3
5: t5 = b * b
6: t6 = t 4 + t5
7: X = t 6

Example :

We can allocate storage locations for temporaries by examining each in turn and
assigning a temporary to the first location in the field for temporaries that does not contain a live
temporary. If a temporary cannot be assigned to any previously created location, add a new
location to the data area for the current procedure. In many cases, temporaries can be packed into
registers rather than memory locations, as in the next section.
Example .

The six temporaries in the basic block can be packed into two locations. These locations
correspond to t 1 and t 2 in:

1: t 1 = a * a ,2: t 2 = a * b,3: t2 = 2 * t2 ,4: t1 = t 1 + t2 ,5: t2 = b * b

6: t1 = t1 + t 2 ,7: X = t1

DATA FLOW EQUATIONS:

Data analysis is needed for global code optimization, e.g.: Is a variable live on exit from a block?
Does a definition reach a certain point in the code? Data flow equations are used to collect
dataflow information A typical dataflow equation has the form

Out[s]=Gen[s]U(in[s]-kill[s])
The notion of generation and killing depends on the dataflow analysis problem to be
solved Let's first consider Reaching Definitions analysis for structured programs A definition of
a variable x is a statement that assigns or may assign a value to x An assignment to x is an
unambiguous definition of x An ambiguous assignment to x can be an assignment to a pointer or
a function call where x is passed by reference When x is defined, we say the definition is
generated An unambiguous definition of x kills all other definitions of x When all definitions of
x are the same at a certain point, we can use this information to do some optimizations Example:
all definitions of x define x to be 1. Now, by performing constant folding, we can do strength
reduction if x is used in z=x*y.

GLOBAL OPTIMIZATIONS, DATA-FLOW ANALYSIS

 So far we were only considering making changes within one basic block. With some
additional analysis, we can apply similar optimizations across basic blocks, making them global
optimizations. It‘s worth pointing out that global in this case does not mean across the entire
program. We usually only optimize one function at a time. Interprocedural analysis is an even
larger task, one not even attempted by some compilers. The additional analysis the optimizer
must do to perform optimizations across basic blocks is called data-flow analysis. Data-flow
analysis is much more complicated than control-flow analysis.
Let‘s consider a global common sub-expression elimination optimization as our example.
Careful analysis across blocks can determine whether an expression is alive on entry to a block.
Such an expression is said to be available at that point.
Once the set of available expressions is known, common sub-expressions can be
eliminated on a global basis. Each block is a node in the flow graph of a program. The successor
set (succ(x)) for a node x is the set of all nodes that x directly flows into. The predecessor set
(pred(x)) for a node x is the set of all nodes that flow directly into x. An expression is defined at
the point where it is assigned a value and killed when one of its operands is subsequently
assigned a new value. An expression is available at some point p in a flow graph if every path
leading to p contains a prior definition of that expression which is not
subsequently killed.

avail[B] = set of expressions available on entry to block B

exit[B] = set of expressions available on exit from B
avail[B] = ∩ exit[x]: x ∈ pred[B] (i.e. B has available the intersection of the
exit of its predecessors)
killed[B] = set of the expressions killed in B
defined[B] = set of expressions defined in B
exit[B] = avail[B] - killed[B] + defined[B]
avail[B] = ∩ (avail[x] - killed[x] + defined[x]) : x ∈ pred[B]

Here is an algorithm for global common sub-expression elimination:

1) First, compute defined and killed sets for each basic block (this does not involve any of its
redecessors or successors).
2) Iteratively compute the avail and exit sets for each block by running the following algorithm
until you hit a stable fixed point:
a) Identify each statement s of the form a = b op c in some block B such that b op c is
available at the entry to B and neither b nor c is redefined in B prior to s.
b) Follow flow of control backward in the graph passing back to but not through each
block that defines b op c. The last computation of b op c in such a block reaches s.
c) After each computation d = b op c identified in step 2a, add statement t = d to that
block where t is a new temp.
d) Replace s by a = t.
Lets try an example to make things clearer:
main:
BeginFunc 28;
b=a+2;
c=4*b;
tmp1 = b < c;
ifNZ tmp1 goto L1 ;
b=1;
L1:
d=a+2;
EndFunc ;

First, divide the code above into basic blocks. Now calculate the available expressions
for each block. Then find an expression available in a block and perform step 2c above.
What common subexpression can you share between the two blocks? What if the above
code were:
main:
BeginFunc 28;
b=a+2;
c=4*b;
tmp1 = b < c ;
IfNZ tmp1 Goto L1 ;
b=1;
z = a + 2 ; <========= an additional line here
L1:
d=a+2;
EndFunc ;

Common Sub expression Elimination

Two operations are common if they produce the same result. In such a case, it is likely more
efficient to compute the result once and reference it the second time rather than re-evaluate it. An
expression is alive if the operands used to compute the expression have not been changed. An
expression that is no longer alive is dead.

main()
{
int x, y, z;
x = (1+20)* -x;
y = x*x+(x/y);
y = z = (x/y)/(x*x);
}
straight translation:
tmp1 = 1 + 20 ;
tmp2 = -x ;
x = tmp1 * tmp2 ;
tmp3 = x * x ;
tmp4 = x / y ;
y = tmp3 + tmp4 ;
tmp5 = x / y ;
tmp6 = x * x ;
z = tmp5 / tmp6 ;
y=z;

What sub-expressions can be eliminated? How can valid common sub-expressions (live ones) be
determined? Here is an optimized version, after constant folding and propagation and elimination
of common sub-expressions:
tmp2 = -x ;
x = 21 * tmp2 ;
tmp3 = x * x ;
tmp4 = x / y ;
y = tmp3 + tmp4 ;
tmp5 = x / y ;
z = tmp5 / tmp3 ;
y=z;

Induction Variable Elimination

Constant folding refers to the evaluation at compile-time of expressions whose
operands are known to be constant. In its simplest form, it involves determining that all of the
operands in an expression are constant-valued, performing the evaluation of the expression at
compile-time, and then replacing the expression by its value. If an expression such as 10 + 2 * 3
is encountered, the compiler can compute the result at compile-time (16) and emit code as if the
input contained the result rather than the original expression. Similarly, constant conditions, such
as a conditional branch if a < b goto L1 else goto L2 where a and b are constant can be replaced
by a Goto L1 or Goto L2 depending on the truth of the expression evaluated at compile-time.
The constant expression has to be evaluated at least once, but if the compiler does it, it means
you don‘t have to do it again as needed during runtime. One thing to be careful about is that the
compiler must obey the grammar and semantic rules from the source language that apply to
expression evaluation, which may not necessarily match the language you are writing the
compiler in. (For example, if you were writing an APL compiler, you would need to take care
that you were respecting its Iversonian precedence rules). It should also respect the expected
treatment of any exceptional conditions (divide by zero, over/underflow). Consider the Decaf
code on the far left and its un optimized TAC translation in the middle, which is then
transformed by constant-folding on the far right:
a = 10 * 5 + 6 - b; _tmp0 = 10 ;
_tmp1 = 5 ;
_tmp2 = _tmp0 * _tmp1 ;
_tmp3 = 6 ;
_tmp4 = _tmp2 + _tmp3 ;
_tmp5 = _tmp4 – b;
a = _tmp5 ;
_tmp0 = 56 ; _tmp1 = _tmp0 – b ; a = _tmp1 ;
Constant-folding is what allows a language to accept constant expressions where a constant is
required (such as a case label or array size) as in these C language examples:

int arr[20 * 4 + 3];

switch (i) {
case 10 * 5: ...
}
In both snippets shown above, the expression can be resolved to an integer constant at compile
time and thus, we have the information needed to generate code. If either expression involved a
variable, though, there would be an error. How could you rewrite the grammar to allow the
grammar to do constant folding in case statements? This situation is a classic example of the gray
area between syntactic and semantic analysis.

Live Variable Analysis

A variable is live at a certain point in the code if it holds a value that may be needed in the
future.
Solve backwards:
Find use of a variable This variable is live between statements that have found use as next
statement Recursive until you find a definition of the variable
Using the sets use[B]and de f[B]

de f[B] is the set of variables assigned values in B prior to any use of that variable in B use [B]
is the set of variables whose values may be used in [B] prior to any definition of the variable.

A variable comes live into a block (in in[B]), if it is either used before redefinition of it is
live coming out of the block and is not redefined in the block .A variable comes live out of a
block (in out[B]) if and only if it is live coming into one of its successors

In[B]=use[B] U (out[B]-de f[B])

Out[B]= U in[s]
S succ[B]

Note the relation between reaching-definitions equations: the roles of in and out are interchanged

Copy Propagation
This optimization is similar to constant propagation, but generalized to non-constant
values. If we have an assignment a = b in our instruction stream, we can replace later
occurrences of a with b (assuming there are no changes to either variable in-between). Given the
way we generate TAC code, this is a particularly valuable optimization since it is able to
eliminate a large number of instructions that only serve to copy values from one variable to
another. The code on the left makes a copy of tmp1 in tmp2 and a copy of tmp3 in tmp4. In the
optimized version on the right, we eliminated those unnecessary copies and propagated the
original variable into the later uses:
tmp2 = tmp1 ;
tmp3 = tmp2 * tmp1;
tmp4 = tmp3 ;
tmp5 = tmp3 * tmp2 ;
c = tmp5 + tmp4 ;
tmp3 = tmp1 * tmp1 ;
tmp5 = tmp3 * tmp1 ;
c = tmp5 + tmp3 ;

We can also drive this optimization "backwards", where we can recognize that the original
assignment made to a temporary can be eliminated in favor of direct assignment to the final goal:
tmp1 = LCall _Binky ;
a = tmp1;
tmp2 = LCall _Winky ;
b = tmp2 ;
tmp3 = a * b ;
c = tmp3 ;
a = LCall _Binky;
b = LCall _Winky;
c=a*b;

IMPORTANT QUESTIONS:

1. What is DAG? Explain the applications of DAG.

2. Explain briefly about code optimization and its scope in improving the code.
3. Construct the DAG for the following basic block:
D := B*C
E :=A+B
B := B+C
A := E-D.
3. Explain Detection of Loop Invariant Computation
4. Explain Code Motion.

ASSIGNMENT QUESTIONS:

1. What is loops? Explain about the following terms in loops:

(a)Dominators
(b) Natural loops
(c) Inner loops
(d) pre-headers.
2. Write short notes on Global optimization?
 OBJECT CODE GENERATION

Machine dependent code optimization:

In final code generation, there is a lot of opportunity for cleverness in generating efficient
target code. In this pass, specific machines features (specialized instructions, hardware pipeline
abilities, register details) are taken into account to produce code optimized for this particular
architecture.

Register Allocation

One machine optimization of particular importance is register allocation, which is

perhaps the single most effective optimization for all architectures. Registers are the fastest kind
of memory available, but as a resource, they can be scarce. The problem is how to minimize
traffic between the registers and what lies beyond them in the memory hierarchy to eliminate
time wasted sending data back and forth across the bus and the different levels of caches. Your
Decaf back-end uses a very naïve and inefficient means of assigning registers, it just fills them
before performing an operation and spills them right afterwards. A much more effective strategy
would be to consider which variables are more heavily in demand and keep those in registers and
spill those that are no longer needed or won't be needed until much later. One common register
allocation technique is called "register coloring", after the central idea to view register allocation
as a graph coloring problem. If we have 8 registers, then we try to color a graph with eight
different colors. The graph‘s nodes are made of "webs" and the arcs are determined by
calculating interference between the webs. A web represents a variable‘s definitions, places
where it is assigned a value (as in x = …), and the possible different uses of those definitions (as
in y = x + 2). This problem, in fact, can be approached as another graph. The definition and uses
of a variable are nodes, and if a definition reaches a use, there is an arc between the two nodes. If
two portions of a variable‘s definition-use graph are unconnected, then we have two separate
webs for a variable. In the interference graph for the routine, each node is a web. We seek to
determine which webs don't interfere with one another, so we know we can use the same register
for those two variables. For example, consider the following code:

i = 10;
j = 20;
x = i + j;
y = j + k;
We say that i interferes with j because at least one pair of i‘s definitions and uses is
separated by a definition or use of j, thus, i and j are "alive" at the same time. A variable is alive
between the time it has been defined and that definition‘s last use, after which the variable is
dead. If two variables interfere, then we cannot use the same register for each. But two variables
that don't interfere can since there is no overlap in the liveness and can occupy the same register.
Once we have the interference graph constructed, we r-color it so that no two adjacent nodes
share the same color (r is the number of registers we have, each color represents a different
register). You may recall that graph-coloring is NP-complete, so we employ a heuristic rather
than an optimal algorithm. Here is a simplified version of something that might be used:
1. Find the node with the least neighbors. (Break ties arbitrarily.)
2. Remove it from the interference graph and push it onto a stack
3. Repeat steps 1 and 2 until the graph is empty.
4. Now, rebuild the graph as follows:
a. Take the top node off the stack and reinsert it into the graph
b. Choose a color for it based on the color of any of its neighbors presently in the
graph, rotating colors in case there is more than one choice.
c. Repeat a and b until the graph is either completely rebuilt, or there is no color
available to color the node.
If we get stuck, then the graph may not be r-colorable, we could try again with a different
heuristic, say reusing colors as often as possible. If no other choice, we have to spill a variable to
memory.

Instruction Scheduling:
Another extremely important optimization of the final code generator is instruction
scheduling. Because many machines, including most RISC architectures, have some sort of
pipelining capability, effectively harnessing that capability requires judicious ordering of
instructions. In MIPS, each instruction is issued in one cycle, but some take multiple cycles to
complete. It takes an additional cycle before the value of a load is available and two cycles for a
branch to reach its destination, but an instruction can be placed in the "delay slot" after a branch
and executed in that slack time. On the left is one arrangement of a set of instructions that
requires 7 cycles. It assumes no hardware interlock and thus explicitly stalls between the second
and third slots while the load completes and has a Dead cycle after the branch because the delay
slot holds a noop. On the right, a more Favorable rearrangement of the same instructions will
execute in 5 cycles with no dead Cycles.

lw $t2, 4($fp)
lw $t3, 8($fp)
noop
add $t4, $t2, $t3
subi $t5, $t5, 1
goto L1
noop
lw $t2, 4($fp)
lw $t3, 8($fp)
subi $t5, $t5, 1
goto L1
add $t4, $t2, $t3
Register Allocation

One machine optimization of particular importance is register allocation, which is

perhaps the single most effective optimization for all architectures. Registers are the fastest kind
of memory available, but as a resource, they can be scarce. The problem is how to minimize
traffic between the registers and what lies beyond them in the memory hierarchy to eliminate
time wasted sending data back and forth across the bus and the different levels of caches. Your
Decaf back-end uses a very naïve and inefficient means of assigning registers, it just fills them
before performing an operation and spills them right afterwards. A much more effective strategy
would be to consider which variables are more heavily in demand and keep those in registers and
spill those that are no longer needed or won't be needed until much later. One common register
allocation technique is called "register coloring", after the central idea to view register allocation
as a graph coloring problem. If we have 8 registers, then we try to color a graph with eight
different colors. The graph‘s nodes are made of "webs" and the arcs are determined by
calculating interference between the webs. A web represents a variable‘s definitions, places
where it is assigned a value (as in x = …), and the possible different uses of those definitions (as
in y = x + 2). This problem, in fact, can be approached as another graph. The definition and uses
of a variable are nodes, and if a definition reaches a use, there is an arc between the two nodes. If
two portions of a variable‘s definition-use graph are unconnected, then we have two separate
webs for a variable. In the interference graph for the routine, each node is a web. We seek to
determine which webs don't interfere with one another, so we know we can use the same register
for those two variables. For example, consider the following code:

i = 10;
j = 20;
x = i + j;
y = j + k;
We say that i interferes with j because at least one pair of i‘s definitions and uses is
separated by a definition or use of j, thus, i and j are "alive" at the same time. A variable is alive
between the time it has been defined and that definition‘s last use, after which the variable is
dead. If two variables interfere, then we cannot use the same register for each. But two variables
that don't interfere can since there is no overlap in the liveness and can occupy the same register.
Once we have the interference graph constructed, we r-color it so that no two adjacent nodes
share the same color (r is the number of registers we have, each color represents a different
register). You may recall that graph-coloring is NP-complete, so we employ a heuristic rather
than an optimal algorithm. Here is a simplified version of something that might be used:

1. Find the node with the least neighbors. (Break ties arbitrarily.)
2. Remove it from the interference graph and push it onto a stack
3. Repeat steps 1 and 2 until the graph is empty.
4. Now, rebuild the graph as follows:
a. Take the top node off the stack and reinsert it into the graph
 b. Choose a color for it based on the color of any of its neighbors presently in the graph,
rotating colors in case there is more than one choice.
c. Repeat a and b until the graph is either completely rebuilt, or there is no color available
to color the node.
If we get stuck, then the graph may not be r-colorable, we could try again with a different
heuristic, say reusing colors as often as possible. If no other choice, we have to spill a variable to
memory.

CODE GENERATION:

The code generator generates target code for a sequence of three-address statement. It
considers each statement in turn, remembering if any of the operands of the statement are
currently in registers, and taking advantage of that fact, if possible. The code-generation uses
descriptors to keep track of register contents and addresses for names.

1. A register descriptor keeps track of what is currently in each register. It is consulted whenever
a new register is needed. We assume that initially the register descriptor shows that all registers
are empty. (If registers are assigned across blocks, this would not be the case). As the code
generation for the block progresses, each register will hold the value of zero or more names at
any given time.

2. An address descriptor keeps track of the location (or locations) where the current value of the
name can be found at run time. The location might be a register, a stack location, a memory
address, or some set of these, since when copied, a value also stays where it was. This
information can be stored in the symbol table and is used to determine the accessing method for
a name.

CODE GENERATION ALGORITHM :

for each X = Y op Z do

- Invoke a function getreg to determine location L where X must be stored. Usually L is a

register.
- Consult address descriptor of Y to determine Y'. Prefer a register for Y'. If value of Y not
already in L generate

Mov Y', L

- Generate

op Z', L
Again prefer a register for Z. Update address descriptor of X to indicate X is in L. If L is a
register update its descriptor to indicate that it contains X and remove X from all other register
descriptors.

. If current value of Y and/or Z has no next use and are dead on exit from block and are in
registers, change register descriptor to indicate that they no longer contain Y and/or Z.

The code generation algorithm takes as input a sequence of three-address statements constituting
a basic block. For each three-address statement of the form x := y op z we perform the following
actions:

1. Invoke a function getreg to determine the location L where the result of the
computation y op z should be stored. L will usually be a register, but it could also be a
memory location. We shall describe getreg shortly.

2. Consult the address descriptor for u to determine y', (one of) the current location(s) of
y. Prefer the register for y' if the value of y is currently both in memory and a register. If
the value of u is not already in L, generate the instruction MOV y', L to place a copy of y
in L.

3. Generate the instruction OP z', L where z' is a current location of z. Again, prefer a
register to a memory location if z is in both. Update the address descriptor to indicate that
x is in location L. If L is a register, update its descriptor to indicate that it contains the
value of x, and remove x from all other register descriptors.

4. If the current values of y and/or y have no next uses, are not live on exit from the
block, and are in registers, alter the register descriptor to indicate that, after execution of
x := y op z, those registers no longer will contain y and/or z, respectively.

FUNCTION getreg:

1. If Y is in register (that holds no other values) and Y is not live and has no next use after
X = Y op Z
then return register of Y for L.
2. Failing (1) return an empty register
3. Failing (2) if X has a next use in the block or op requires register then get a register R, store its
content into M (by Mov R, M) and use it.
4. Else select memory location X as L

The function getreg returns the location L to hold the value of x for the assignment x := y op z.

1. If the name y is in a register that holds the value of no other names (recall that copy
instructions such as x := y could cause a register to hold the value of two or more variables
simultaneously), and y is not live and has no next use after execution of x := y op z, then return
the register of y for L. Update the address descriptor of y to indicate that y is no longer in L.

2. Failing (1), return an empty register for L if there is one.

3. Failing (2), if x has a next use in the block, or op is an operator such as indexing, that requires
a register, find an occupied register R. Store the value of R into memory location (by MOV R,
M) if it is not already in the proper memory location M, update the address descriptor M, and
return R. If R holds the value of several variables, a MOV instruction must be generated for each
variable that needs to be stored. A suitable occupied register might be one whose datum is
referenced furthest in the future, or one whose value is also in memory.

4. If x is not used in the block, or no suitable occupied register can be found, select the memory
location of x as L.

Example :
Stmt code reg desc addr desc

t 1 =a-b mov a,R 0 R 0 contains t 1 t 1 in R0

sub b,R 0
t2 =a-c mov a,R 1 R0 contains t 1 t1 in R0
sub c,R1 R 1 contains t2 t 2 in R1
t3 =t1 +t 2 add R 1 ,R0 R 0contains t3 t3 in R 0
R 1 contains t2 t 2 in R1
d=t3 +t2 add R 1 ,R 0 R 0contains d d in R0
mov R 0 ,d d in R0 and
memory

For example, the assignment d := (a - b) + (a - c) + (a - c) might be translated into the following

three- address code sequence:
t1 = a - b

t2=a-c

t 3 = t 1 + t2

d = t 3 + t2

The code generation algorithm that we discussed would produce the code sequence as shown.
Shown alongside are the values of the register and address descriptors as code generation
progresses.

DAG for Register allocation:

 DAG (Directed Acyclic Graphs) are useful data structures for implementing
transformations on basic blocks. A DAG gives a picture of how the value computed by a
statement in a basic block is used in subsequent statements of the block. Constructing a DAG
from three-address statements is a good way of determining common sub-expressions
(expressions computed more than once) within a block, determining which names are used inside
the block but evaluated outside the block, and determining which statements of the block could
have their computed value used outside the block.

A DAG for a basic block is a directed cyclic graph with the following labels on nodes:

1. Leaves are labeled by unique identifiers, either variable names or constants. From the
operator applied to a name we determine whether the l-value or r-value of a name is needed;
most leaves represent r- values. The leaves represent initial values of names, and we subscript
them with 0 to avoid confusion with labels denoting "current" values of names as in (3) below.

2. Interior nodes are labeled by an operator symbol.

3. Nodes are also optionally given a sequence of identifiers for labels. The intention is
that interior nodes represent computed values, and the identifiers labeling a node are deemed to
have that value.

DAG representation Example:

For example, the slide shows a three-address code. The corresponding DAG is shown. We
observe that each node of the DAG represents a formula in terms of the leaves, that is, the values
possessed by variables and constants upon entering the block. For example, the node labeled t 4
represents the formula

b[4 * i]
that is, the value of the word whose address is 4*i bytes offset from address b, which is the
intended value of t 4 .

Code Generation from DAG

S 1= 4 * i S1=4*i
S2 = addr(A)-4 S 2 = addr(A)-4
S3 = S 2 [S 1 ] S 3 = S2 [S 1 ]
S4=4*i
S5 = addr(B)-4 S 5= addr(B)-4
S 6 = S 5 [S4 ] S6 = S5 [S 4 ]
S7 = S 3 * S6 S 7 = S3 * S 6
S8 = prod+S7
prod = S8 prod = prod + S 7
S9 = I+1
I = S9 I=I+1
If I <= 20 goto (1) If I <= 20 goto (1)

We see how to generate code for a basic block from its DAG representation. The
advantage of doing so is that from a DAG we can more easily see how to rearrange the order of
the final computation sequence than we can starting from a linear sequence of three-address
statements or quadruples. If the DAG is a tree, we can generate code that we can prove is optimal
under such criteria as program length or the fewest number of temporaries used. The algorithm
for optimal code generation from a tree is also useful when the intermediate code is a parse tree.

Rearranging order of the code

Consider following basic

block :

t1=a+b
t2=c+d
t 3 = e -t 2
X = t 1 -t 3

and its DAG given here.

 Here, we briefly consider how the order in which computations are done can affect the
cost of resulting object code. Consider the basic block and its corresponding DAG representation
as shown in the slide.

Rearranging order .

Rearranging the code as

Three adress code
for the DAG t2 = c + d
(assuming only two
registers are t3 = e -t 2
available)
t1 = a + b
MOV a, R0 X = t 1 -t3
ADD b, R0 gives
MOV c, R 1 MOV c, R 0
ADD d, R 1 ADD d, R 0
MOV R0 , t1 Register spilling MOV e, R 1
MOV e, R0 SUB R 0 , R1
SUB R 1 , R0 MOV a, R 0
MOV t1 , R 1 Register reloading ADD b, R0
SUB R 0 , R1 SUB R 1 , R0
MOV R1 , X MOV R 1 , X

If we generate code for the three-address statements using the code generation algorithm
described before, we get the code sequence as shown (assuming two registers R0 and R1 are
available, and only X is live on exit). On the other hand suppose we rearranged the order of the
statements so that the computation of t 1 occurs immediately before that of X as:

t2 = c + d
t3 = e -t 2
t1 = a + b
X = t 1 -t3

Then, using the code generation algorithm, we get the new code sequence as shown (again only
R0 and R1 are available). By performing the computation in this order, we have been able to
save two instructions; MOV R0, t 1 (which stores the value of R0 in memory location t 1 ) and
MOV t 1 , R1 (which reloads the value of t 1 in the register R1).
 IMPORTANT & EXPECTED QUESTIONS:

Construct the DAG for the following basic block:

D := B*C
E :=A+B
B := B+C
A := E-D.

1. What is Object code? Explain about the following object code forms:
(a) Absolute machine-language
(b) Relocatable machine-language
(c) Assembly-language.
2. Explain about Generic code generation algorithm?
3. Write and explain about object code forms?
4. Explain Peephole Optimization

ASSIGNMENT QUESTIONS:

1. Explain about Generic code generation algorithm?

2. Explain about Data-Flow analysis of structured flow graphs.
3. What is DAG? Explain the applications of DAG.