Interprocedural Register Allocation Interference graph The problem: - PDF document

Interprocedural Register Allocation Interference graph The problem: Represent notion of “simultaneously live” using interference graph assign machine resources (registers, stack locations) to hold run-time data • nodes are “units of allocation” • n 1 is linked by an edge to n 2 iff n 1 and n 2 are simultaneously live at some program point Constraint: simultaneously live data allocated to different locations • symmetric, not reflexive, not transitive Two adjacent nodes must be allocated to distinct locations Goal: minimize overhead of stack loads & stores and register moves Craig Chambers 265 CSE 401 Craig Chambers 266 CSE 401 Units of allocation A bigger example a := ... What are the units of allocation? b := ... • option 1: variables c := ... • option 2: distinct connected def/use chains ( live ranges ) ... b ... ... a ... Example: d := ... x := 5 ... d ... ... c ... a := ... a := ... y := x ... x ... ... d ... x := y + 1 x := 3 c := ... ... d ... ... x ... e := ... ... a ... ... e ... ... b ... Craig Chambers 267 CSE 401 Craig Chambers 268 CSE 401

Computing interference graph Allocating registers using interference graph Construct interference graph as side-effect of Register allocation via graph coloring: allocating variables to k registers live variables analysis is equivalent to • easy if variables are units of allocation finding a k -coloring of the interference graph Construct incrementally as live vars sets modified k -coloring: color nodes of graph using up to k colors, • when add a new var to live vars set, adjacent nodes have different colors create edge from new var to all existing vars • when merge two live vars sets, Optimal graph coloring: NP-complete add one sets’ vars to other set • need algorithms + heuristics to do a decent job in reasonable time Craig Chambers 269 CSE 401 Craig Chambers 270 CSE 401 Spilling A simple greedy allocation algorithm If can’t find k -coloring of interference graph, For all nodes, in decreasing order of weight: must spill some variables to stack, • try to allocate node to a register, if possible until the resulting interference graph is k -colorable • if not, allocate to a stack location Which to spill? Reserve 2-3 scratch registers to use when manipulating nodes • least frequently accessed variables allocated to stack locations • most conflicting variables (nodes with highest out-degree) Weighted interference graph : weight( n ) = sum over all references (uses and defs) r of n : execution frequency of r Try to spill nodes with lowest weight and highest out-degree, if forced to spill Craig Chambers 271 CSE 401 Craig Chambers 272 CSE 401

Example Improvement #1: add simplification phase [Chaitin 82] a 1 a 2 Weight Order: Key idea: c nodes with < k neighbors can be allocated d after all their neighbors, but still guaranteed a register e b a 2 b So remove them from the graph first a 1 • reduces the degree of the remaining nodes e d c Must resort to spilling only when all remaining nodes have degree ≥ k Assume 3 registers available Craig Chambers 273 CSE 401 Craig Chambers 274 CSE 401 The algorithm Example while interference graph not empty: a 1 a 2 Weight Order: while there exists a node with < k neighbors: c remove it from the graph d push it on a stack b e a 2 b if all remaining nodes have k neighbors, then blocked : a 1 e pick node with lowest weight/degree to spill d c remove node from graph push it on the stack Assume 3 registers available while stack not empty: pop node from stack put back in graph if possible, allocate to register different from all its neighbors otherwise, allocate to stack Craig Chambers 275 CSE 401 Craig Chambers 276 CSE 401

Example Another example A a 1 a 2 Weight Order: c B D d e b a 2 b a 1 C e d c Assume 2 registers available Assume 2 registers available Craig Chambers 277 CSE 401 Craig Chambers 278 CSE 401 Coalescing and preference hints Live range splitting When generating code for copy statement like x = y , If a long live range cannot be allocated a register, if x and y were assigned same register, can split it into multiple separate live ranges, then skip generating a move instruction linked by copy statements • can allocate each separate piece separately If register allocator sees x = y , • since each piece is shorted, each may interfere with fewer and x & y are not simultaneously live, things, and so be more allocatable then it should prefer to assign x and y to same register The reverse of coalescing One implementation strategy: coalesce x and y into same unit of allocation (similar effect as copy propagation) Pretty tricky to decide where to split, where to coalesce, etc. + avoids generating code for simple copies to come up with good overall allocations − can cause more spilling Another strategy: add preference hints that two things be allocated to same register • can assign costs to (violating) preferences • when picking a register, favor most preferred available register Craig Chambers 279 CSE 401 Craig Chambers 280 CSE 401

Handling calling conventions How should register allocator deal w/ calling conventions? Simple: calling-convention-oblivious register allocation • spill all live caller-save registers before call, restore after call • save all callee-save registers at entry, restore at return Better: calling-convention-aware register allocation • add preferred registers for formals, actuals, results • variables live across a call interfere with caller-save regs • allocator knows to avoid these registers, save/restore code turns into normal spills • live range splitting for before/during/after call could be good • procedure entry "assigns" to all callee-save registers, procedure exit "reads" all callee-save registers • simultaneously live with all variables in procedure � allocator knows must spill these registers if used Gives limited form of interprocedural register allocation • leaf routines (try to) use only caller-save registers • routines with calls use callee-save registers for variables live across calls Craig Chambers 281 CSE 401