Download Local Optimizations in Compiler Design: Intermediate Code and Techniques and more Exams Computer Science in PDF only on Docsity!
Prof. Su ECS 142 Lecture 15 1
Local Optimizations
ECS 142
Prof. Su ECS 142 Lecture 15 2
Extra Credit: Optimization (due Dec 12)
- Up to 5%
- Will be factored in after curve been determined
- 15 test cases
- Minus 1% for each failed test (doesn’t run correctly)
- Max 4 failed tests to receive any extra credits
- Calculate average speedup over coolc
- In terms of # of instructions executed
- Average over passed tests
- Split into rough equivalent classes to assign credits
Prof. Su ECS 142 Lecture 15 3
Lecture Outline
- Intermediate code
- Local optimizations
- Next time: global optimizations
Prof. Su ECS 142 Lecture 15 4
Code Generation Summary
- We have discussed
- Runtime organization
- Simple stack machine code generation
- Improvements to stack machine code generation
- Our compiler goes directly from AST to
assembly language
- And does not perform optimizations
- Most real compilers use intermediate
languages
Prof. Su ECS 142 Lecture 15 5
Why Intermediate Languages?
- When to perform optimizations
- On AST
- Pro: Machine independent
- Con: Too high level
- On assembly language
- Pro: Exposes optimization opportunities
- Con: Machine dependent
- Con: Must reimplement optimizations when retargetting
- On an intermediate language
- Pro: Machine independent
- Pro: Exposes optimization opportunities
- Con: One more language to worry about Prof. Su ECS 142 Lecture 15 6
Intermediate Languages
- Each compiler uses its own intermediate
language
- IL design is still an active area of research
- Intermediate language = high-level assembly
language
- Uses register names, but has an unlimited number
- Uses control structures like assembly language
- Uses opcodes but some are higher level
- E.g., push translates to several assembly instructions
- Most opcodes correspond directly to assembly opcodes
Prof. Su ECS 142 Lecture 15 7
Three-Address Intermediate Code
- Each instruction is of the form
x := y op z
- y and z can be only registers or constants
- Just like assembly
- Common form of intermediate code
- The AST expression x + y * z is translated as
t 1 := y * z
t 2 := x + t 1
- Each subexpression has a “name” Prof. Su ECS 142 Lecture 15 8
Generating Intermediate Code
- Similar to assembly code generation
- Major difference
- Use any number of IL registers to hold intermediate results
Prof. Su ECS 142 Lecture 15 9
Generating Intermediate Code (Cont.)
- igen(e, t) function generates code to compute
the value of e in register t
igen(e 1 + e 2 , t) = igen(e 1 , t 1 ) (t 1 is a fresh register) igen(e 2 , t 2 ) (t 2 is a fresh register) t := t 1 + t (^2)
- Unlimited number of registers
⇒ simple code generation
Prof. Su ECS 142 Lecture 15 10
Intermediate Code Notes
- You should be able to use intermediate code
- At the level discussed in lecture
- You are not expected to know how to generate
intermediate code
- Because we won’t discuss it
- But really just a variation on code generation...
Prof. Su ECS 142 Lecture 15 11
Notes
- Dragon book has very good coverage on
- Local and global optimizations (Ch. 10)
- Book on reserve in library
- Also good coverage on
- Intermediate code (Ch. 8)
- Code generation (Ch. 9)
- Not required, but recommended readings
Prof. Su ECS 142 Lecture 15 12
An Intermediate Language
P → S P | ε S → id := id op id | id := op id | id := id | push id | id := pop | if id relop id goto L | L: | jump L
- id’s are register names
- Constants can replace id’s
- Typical operators: +, -, *
Prof. Su ECS 142 Lecture 15 19
A Classification of Optimizations
- For languages like C and Cool there are three
granularities of optimizations
- Local optimizations
- Apply to a basic block in isolation
- Global optimizations (a.k.a. intra-procedural)
- Apply to a control-flow graph (method body) in isolation
- Inter-procedural optimizations
- Apply across method boundaries
- Most compilers do (1), many do (2) and very
few do (3)
Prof. Su ECS 142 Lecture 15 20
Cost of Optimizations
- In practice, a conscious decision is made not
to implement the fanciest optimization known
- Why?
- Some optimizations are hard to implement
- Some optimizations are costly in terms of compilation time
- The fancy optimizations are both hard and costly
- The goal
- Maximum improvement with minimum cost
Prof. Su ECS 142 Lecture 15 21
Local Optimizations
- The simplest form of optimizations
- No need to analyze the whole procedure body
- Just the basic block in question
- Example: algebraic simplification
Prof. Su ECS 142 Lecture 15 22
Algebraic Simplification
- Some statements can be deleted x := x + 0 x := x * 1
- Some statements can be simplified x := x * 0 ⇒ x := 0 y := y ** 2 ⇒ y := y * y x := x * 8 ⇒ x := x << 3 x := x * 15 ⇒ t := x << 4; x := t - x (on some machines << is faster than *; but not on all!)
Prof. Su ECS 142 Lecture 15 23
Constant Folding
- Operations on constants can be computed at
compile time
- In general, if there is a statement
x := y op z
- And y and z are constants
- Then y op z can be computed at compile time
- Example: x := 2 + 2 ⇒ x := 4
- Example: if 2 < 0 jump L can be deleted
- When might constant folding be dangerous?
Prof. Su ECS 142 Lecture 15 24
Flow of Control Optimizations
- Eliminating unreachable code:
- Code that is unreachable in the control-flow graph
- Basic blocks that are not the target of any jump or “fall through” from a conditional
- Such basic blocks can be eliminated
- Why would such basic blocks occur?
- Removing unreachable code makes the
program smaller
- And sometimes also faster
- Due to memory cache effects (increased spatial locality)
Prof. Su ECS 142 Lecture 15 25
Single Assignment Form
- Some optimizations are simplified if each
register occurs only once on the left-hand
side of an assignment
- Intermediate code can be rewritten to be in
single assignment form
x := z + y b := z + y a := x ⇒ a := b x := 2 * x x := 2 * b (b is a fresh register)
- More complicated in general, due to loops Prof. Su ECS 142 Lecture 15 26
Common Subexpression Elimination
- Assume
- Basic block is in single assignment form
- A definition x := is the first use of x in a block
- All assignments with same rhs compute the
same value
- Example: x := y + z x := y + z … ⇒ … w := y + z w := x (the values of x, y, and z do not change in the … code)
Prof. Su ECS 142 Lecture 15 27
Copy Propagation
- If w := x appears in a block, all subsequent
uses of w can be replaced with uses of x
- Example: b := z + y b := z + y a := b ⇒ a := b x := 2 * a x := 2 * b
- This does not make the program smaller or
faster but might enable other optimizations
- Constant folding
- Dead code elimination
Prof. Su ECS 142 Lecture 15 28
Copy Propagation and Constant Folding
- Example: a := 5 a := 5 x := 2 * a ⇒ x := 10 y := x + 6 y := 16 t := x * y t := x << 4
Prof. Su ECS 142 Lecture 15 29
Copy Propagation and Dead Code Elimination
If
w := rhs appears in a basic block w does not appear anywhere else in the program
Then
the statement w := rhs is dead and can be eliminated
- Dead = does not contribute to the program’s result
Example: (a is not used anywhere else)
x := z + y b := z + y b := z + y a := x ⇒ a := b ⇒ x := 2 * b x := 2 * a x := 2 * b Prof. Su ECS 142 Lecture 15 30
Applying Local Optimizations
- Each local optimization does very little by
itself
- Typically optimizations interact
- Performing one optimizations enables other opt.
- Typical optimizing compilers repeatedly
perform optimizations until no improvement is
possible
- The optimizer can also be stopped at any time to limit the compilation time
Prof. Su ECS 142 Lecture 15 37
An Example
- Constant folding: a := x * x b := 3 c := x d := x * x e := 6 f := a + d g := e * f
Prof. Su ECS 142 Lecture 15 38
An Example
- Common subexpression elimination: a := x * x b := 3 c := x d := x * x e := 6 f := a + d g := e * f
Prof. Su ECS 142 Lecture 15 39
An Example
- Common subexpression elimination: a := x * x b := 3 c := x d := a e := 6 f := a + d g := e * f
Prof. Su ECS 142 Lecture 15 40
An Example
- Copy propagation: a := x * x b := 3 c := x d := a e := 6 f := a + d g := e * f
Prof. Su ECS 142 Lecture 15 41
An Example
- Copy propagation: a := x * x b := 3 c := x d := a e := 6 f := a + a g := 6 * f
Prof. Su ECS 142 Lecture 15 42
An Example
- Dead code elimination: a := x * x b := 3 c := x d := a e := 6 f := a + a g := 6 * f
Prof. Su ECS 142 Lecture 15 43
An Example
- Dead code elimination: a := x * x
f := a + a g := 6 * f
Prof. Su ECS 142 Lecture 15 44
Peephole Optimizations on Assembly Code
- The optimizations presented before work on
intermediate code
- They are target independent
- But they can be applied on assembly language also
- Peephole optimization is an effective
technique for improving assembly code
- The “peephole” is a short sequence of (usually contiguous) instructions
- The optimizer replaces the sequence with another equivalent one (but faster)
Prof. Su ECS 142 Lecture 15 45
Peephole Optimizations (Cont.)
- Write peephole optimizations as replacement
rules
i 1 , …, in → j 1 , …, j (^) m where the rhs is the improved version of the lhs
move $a $b, move $b $a → move $a $b
- Works if move $b $a is not the target of a jump
- Another example
addiu $a $a i, addiu $a $a j → addiu $a $a i+j
Prof. Su ECS 142 Lecture 15 46
Peephole Optimizations (Cont.)
- Many (but not all) of the basic block
optimizations can be cast as peephole
optimizations
- Example: addiu $a $b 0 → move $a $b
- Example: move $a $a →
- These two together eliminate addiu $a $a 0
- Just like for local optimizations, peephole
optimizations need to be applied repeatedly to
get maximum effect
Prof. Su ECS 142 Lecture 15 47
Local Optimizations. Notes.
- Intermediate code is helpful for many
optimizations
- Many simple optimizations can still be applied
on assembly language
- “Program optimization” is grossly misnamed
- Code produced by “optimizers” is not optimal in any reasonable sense
- “Program improvement” is a more appropriate term
- Next time: global optimizations
