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 Local Register Allocation Within a basic block –Top-down Assign registers to the most heavily used variables –Traverse the block –Count uses –Use count as a priority function –Assign registers to higher priority variables first Advantage –Heavily used values reside in registers Disadvantage –Does not consider non-uniform distribution of uses

3 Local Register Allocation Is is sufficient? –Does not take into account that some instructions (e.g. those in loops) execute more frequently –Forces us to store/load at basic block endpoints since each block has no knowledge of the context of others. We need Global Register Allocation –Live ranges will be defined differently –Cost of spilling will depend on frequencies and locations of uses.

4 Global register allocation Global register allocation can be seen as a graph coloring problem Basic idea: –Identify the live range of each variable –Build an interference graph that represents conflicts between live ranges (two nodes are connected if the variables they represent are live at the same moment) Issue : copy statements –Coalesce live ranges? –Try to assign as many colors to the nodes of the graph as there are registers so that two neighbors have different colors. In what order should we assign colors? Must define priority

5 Global register allocation Estimating the cost of not assigning a register. –Size of live range –Number of uses/definitions –Frequency of execution –Number of loads/stores needed. –Cost of loads/stores needed.

6 Global register allocation Priority-based graph coloring Live Range = a group of flowgraph nodes in which a variable is defined and referenced. –No outside definition of the variable reaches a reference inside the live range –The definitions of the variables inside the live range do not reach uses of that variable outside the live range. –The live range is not necessarily contiguous.

7 Global register allocation Priority-based graph coloring We will need LOADs at the entry points of the live range and STOREs at the exit points. Consider: =a a= =a

8 Global register allocation Priority-based graph coloring We will need LOADs at the entry points of the live range and STOREs at the exit points. LOAD conditions: –There is a reference before a definition AND BB is an entry point to the live range BB is not an entry point but its predecessor has a procedure call that accesses the variable. STORE conditions: –The live range contains definitions of the variable –The variable is not dead on exit BB is exit, but variable is not local BB ends in procedure call that accesses variable Variable is live in next block (this may apply after a split) Variable is LOADed in next block.

9 Global register allocation Priority-based graph coloring LR(x) = {B | x is live at B}  {B | x is reaching in B } –x live at B = x is referenced in B, or x live at the end of B –x reaching in B = a definition of x reaches B a use of x (backwards-) reaches B

10 Global register allocation Priority-based graph coloring Interference graph: –nodes : live ranges of variables –edges : two live ranges are connected if their intersection in non-empty –meaning : if two live ranges are connected, then the variables they represent are both live at the same point, so they will need to be stored in different registers

11 Global register allocation Priority-based graph coloring Priorities: –Each live range lr is assigned a priority that measures the relative benefits of assigning it to a register –The priority function is –The size of the live range is the number of nodes in it. –We must take into account loop structure.

12 Global register allocation Priority-based graph coloring TOTALSAVE (lr) =  (NETSAVE B  nestingdepth B ) NETSAVE = LOADSAVE  num_uses + STORESAVE  num_defs  MOVECOST  num_moves num_moves is 0, 1, or 2. It is determined by the number of LOADs and STOREs needed at entry and exit points. (see slide 8)slide 8

13 Global register allocation Priority-based graph coloring LOADSAVE = The amount of execution time saved for each use of a variable residing in a register rather than memory STORESAVE = The amount of execution time saved for each definition of a variable residing in a register rather than memory MOVECOST = The cost of a memory-to-register or register-to- memory move. if the first occurrence of a variable in its live range is a use, then it must be loaded from memory if the variable is live at the end of its live range, then it must be stored to memory.

14 Global register allocation Priority-based graph coloring unconstrained live range : a live range that has fewer neighbors in the interference graph than there are registers. It can ALWAYS be colored, so we color it last. constrained live range : any range that is not unconstrained :)

15 Global register allocation Priority-based graph coloring The coloring algorithm 1. Identify and set aside the unconstrained live ranges 2. While there remain constrained live ranges and more registers to be assigned, repeat steps (a) to (c) (a) Compute the priority of each live range (b) Assign a color to the live range lr with highest priority (c) Update available color info for lr's neighbors. Check if any need to be split and, if so, apply splitting algorithm. 3. Assign colors to the unconstrained live ranges

16 Global register allocation Priority-based graph coloring The splitting algorithm 1. Find a block in lr in which the first appearance is a definition, preferably an entry point. Else, start with the first block that contains a use. This basic block must have available registers. 2. For each successor of the first block, check if it can be added to the new live range 3. Once the new live range has been determined, update the interference graph