Register allocation

1. Register allocation • Consists of two parts: • register allocation • What will be stored in registers • Only unambiguous values • register assignment • Which register will be assigned to each variable? • Goal : minimize spills • How hard is it? • BB w/ one size of data: polynomial • otherwise, NP-complete • based on graph coloring.

2. Code generation issues • Generating code for simple expressions • If the expression is represented by a tree, a post-order walk gives an evaluation sequence • Changing the evaluation sequence may result in code that uses fewer registers. • Idea: find out how many registers are needed for each subtree and evaluate the most expensive one first. • Consider the following algorithm that labels tree nodes with the number of registers needed (for the ILOC architecture): 1, if n is a left leaf, or right leaf and variable label(n) = 0, if n is a right leaf and constant max(labellchild, labelrchild), if labellchild labelrchild labellchild +1, if labellchild == labelrchild

3. Code generation issues • Generating code for simple expressions • The idea behind our algorithm: • Variables need to be loaded in registers, so leafs need one register • For rhs constants we can use opI operations, so no extra register needed • If we need k registers for each subtree, we'll use k for the left one, keep 1 for the result, and then use another k for the right subtree. That's a total of k+1 registers • If we need k registers for one subtree and m<k for the other, then use k for the one subtree, keep the result in 1, use the remaining k-1 (which is at least m) for the other subtree. That's a total of k registers. • When generating code, make sure to evaluate the most expensive subtree first.

4. Code generation issues • Generating code for expressions • What if an expression contains a function call? • Should the compiler be allowed to change the evaluation order? • Big idea #1 wrt to optimizing or moving code around : Be conservative! • Generating code for • boolean operators • relational operators read the book • array references

5. Code generation issues • Generating code for procedure calls • Back to the calling convention issue • Which registers should be caller-saved and which callee-saved? • Consider: Should x be caller- or callee-saved?(Goal : minimize number of save/restores) procedure f( int x, int y) begin int v; v := x * y call g(v); call h(v); return -x; end

6. Optimization • Optimization = transformation that improves the performance of the target code • Optimization • must not change the output • must not cause errors that were not present in the original program • must be worth the effort (profiling often helps). • Which optimizations are most important depends on the program, but generally, loop optimizations, register allocation and instruction scheduling are the most critical. • local optimizations : within basic blocks • global optimizations: within flow graph

7. Constant folding • Definition: • The evaluation at compile time of expressions whose values are known to be constant. • How: Determine that all operands in the expression are constant • always applicable for booleans • almost always applicable for integers (issue: division by zero) • more complicated for floating point (issues: processor's floating point arithmetic, exceptions, etc.) • May be combined with constant propagation.

8. Algebraic simplifications • These include: • Taking advantage of algebraic identities • (x*1) is x • Strength reduction • (x*2) is (x << 1) • Simplifications such as • -(-x) is x • (1 || x) is true • (1 && x) is x • *(& x)is x

9. Copy propagation • Definition: • Given an assignment of the form x = y, replace later uses of x with uses of y (as long as there are no instructions between the assignment and the uses that redefine x or y)

10. Value numbering • Definition: • If two expressions are equivalent, eliminate the computation of one of them. • Locally • when using DAGS • when using linear representation

11. Common subexpression elimination • Definition: • If an expression x+y has been previously computed and the values of x and y have not changed since then, re-use the previous value instead of recomputing it. • Is this the same as value numbering? • Consider j = i+m k = i n = k+m

12. Dead code elimination • A variable is dead at some point if its value is not used on any path from that point to the exit. An instruction is dead if it computes only values that are not used on any path to the exit. Dead code elimination removes dead instructions. • Dead code often arises from other optimizations.

13. Data flow analysis • Goal : • collect information about how a procedure manipulates its data • This information is used in various optimizations • For example, knowledge about what expressions are available at some point helps in common subexpression elimination. • IMPORTANT! • Data flow analysis should never tell us that a transformation is safe when in fact it is not. • It is better to not perform a valid optimization that to perform one that changes the function of the program.

14. Data flow analysis • IMPORTANT! • Data flow analysis should never tell us that a transformation is safe when in fact it is not. • When doing data flow analysis we must be • conservative • do not consider information that may not preserve the behavior of the program • aggressive • try to collect information that is as exact as possible, so we can get the greatest benefit from our optimizations.

15. Global Iterative Data Flow Analysis • Global: • Performed on the flow graph • Goal = to collect information at the beginning and end of each basic block • Iterative: • Construct data flow equations that describe how information flows through each basic block and solve them by iteratively converging on a solution.