Optimization

Optimization

Poor Term

The word "optimization" is not really a good term for the process of making the translated program run faster.  It is theoretically impossible to optimize programs with a program.  A better term for the optimization phase of a compiler would be the "code improvement" phase.

Where Optimizations Can Be Done

Source Language:  The semantic routines can, when source code is being translated, do some optimizations:

• exploiting constant bounds on loops and arrays
• Inhibiting code generation for unreachable code segments (and  generate warning messages that such code exists)
• loop body unrolling
• suppressing code generation for run time checks.  Constant loop bounds with arrays involved, for example, allow for some shortcuts

Intermediate Code:  Two different kinds of optimization strategies are identified--local and global.  For local optimizations, the notion of a basic block is used.  A basic block is a block of intermediated code that is always entered at the top and exited at the bottom.  In between there are no branches into or out of the code.  A program can be viewed as a graph of basic blocks with arrows to a basic block indicating from which points the basic block can be reached and arrows leaving a basic block indicating which next basic blocks can follow this one.

Optimizations within a basic block are called "local."  Optimizations that consider the whole graph are called "global."

local optimizations:  These are fairly easy to do, because they do not required flow analysis among different blocks.  Coupled with code generation, good use of registers,  machine language instructions, etc. during translation from IR to actual code can be done.

global optimizations:  This requires flow analysis.  A major optimization here is common subexpression elimination (e.g., if the compiler can determine that the same code for a subexpression is executed in different blocks with no change to the operands in between, the expression can be evaluated just once, its result saved, and the saved value used wherever that subexpression is to be re-evaluated).  Another big one is moving invariant code out of loops.

Code generation:

• careful allocation of registers so that register values can be reused without reloading
• careful use of instructions on the target machine that help speed execution time
• careful use of hardware addressing modes
• exploitation of hardware features, such as pipelines and caches

Peephole Optimization

• Constant Folding -- e.g., push #3, push #4, adds => push #7
• Strength Reduction -- e.g., push 0(D1), push #2, muls => push 0(D1), shiftLefts
• Null Sequence Determination -- e.g., push 4(D2), push #0, adds => push 4(D2)
• Algebraic Laws -- e.g., push #0, push 2(D3), subs => push 2(D1), negs
• Combining operations -- e.g., mov 0(D1), R1, mov 4(D1) R2 => doublemove 0(D1), R1
• Special Case Instructions -- e.g., push 2(D1), push #1, subs => push 2(D1), decs
• Address Mode Utilization -- e.g., push D0, push #5, adds, pop D0, push (D0) => push 5(D0)

Global Optimizations

Global affect a much broader series of statements than peephole optimization.

• Procedure Inlining
• Loop Optimization (invariant code movement to in front of the loops)

Optimization in Perspective

• Can be as good as hand generated code
• Can be unsafe (consider changing a+b+c to a+c+b if a and c are both very large positive integers and b is a large negative number)
• Cannot make up for poor algorithm choices

Computer Engineering -- Where Hardware and Software Meet

A good computer engineer needs about half hardware and half software. The study of compilers is a good example of where the two disciplines meet.  A computer designer should understand programming languages and compilers well.  That way, the instructions that are included in hardware can be ones that make it possible to generate efficient translated code from source programs.