Progressive Register Allocation for Irregular Architectures

1. Progressive Register Allocation for Irregular Architectures David Koes dkoes@cs.cmu.edu Seth Copen Goldstein seth@cs.cmu.edu March 23, 2005 2005 International Symposium on Code Generation and Optimization

2. eax ebx ecx edx esi edi esp ebp Irregular Architectures • Few registers • Register usage restrictions • address registers, hardwired registers... • Memory operands • Examples: • x86, 68k, ColdFire, ARM Thumb, MIPS16, V800, various DSPs... 2005 International Symposium on Code Generation and Optimization

3. Fewer Registers  More Spills • Used gcc to compile >10,000 functions from Mediabench, Spec95, Spec2000, and micro-benchmarks • Recorded which functions spilled 2005 International Symposium on Code Generation and Optimization

4. Register Usage Restrictions • Instructions may prefer or require a specific subset of registers • x86 multiply instruction imul %edx,%eax// 2 byte instruction imul %edx,%ecx// 3 byte instruction • x86 divide instruction idivl %ecx// eax = edx:eax/ecx 2005 International Symposium on Code Generation and Optimization

5. Memory Operands • Load/store not always needed to access variables allocated to memory • depends upon instruction • still less efficient than register access addl 8(%ebp), %eax vs movl 8(%ebp), %edx addl %edx, %eax 2005 International Symposium on Code Generation and Optimization

6. Register Allocation Challenges • Optimize spill code • with few registers, spilling unavoidable • Model register usage restrictions • Exploit memory operands • affects spilling decisions 2005 International Symposium on Code Generation and Optimization

7. Previous Work 2005 International Symposium on Code Generation and Optimization

8. Our Goals • Expressive • Explicitly represent architectural irregularities and costs • Proper model • An optimum solution results in optimal register allocation • Progressive solution algorithm • more computation  better solution • decent feasible solution obtained quickly • competitive with current allocators 2005 International Symposium on Code Generation and Optimization

9. source a b crossbar 4 4 2 4 2 4 2 instruction sink a b Multicommodity Network Flow (MCNF) 2005 International Symposium on Code Generation and Optimization

10. a b -1 1 imul idiv eax eax edx edx ecx ecx mem mem b c 1 a c Modeling Usage Constraints int foo(int a, int b, int c) { a = a*b; return a/c; } not quite right… 2005 International Symposium on Code Generation and Optimization

11. a b c eax eax edx edx ecx ecx mem mem 1 3 3 3 eax eax edx edx ecx ecx mem mem -1 1 idiv eax edx ecx mem a imul c eax edx ecx mem b Modeling Spills and Moves int foo(int a, int b, int c) { a = a*b; return a/c; } 2005 International Symposium on Code Generation and Optimization

12. Solution: antivariables • flow only through memory • eviction cost = store cost • evict only once Modeling Stores • Simple approach flawed • doesn’t model memory persistency 2005 International Symposium on Code Generation and Optimization

13. Register Allocation as MCNF • Variables  Commodities • Variable Usage  Network Design • Nodes  Allocation Classes (Reg/Mem) • Registers Limits  Node Capacities • Spill Costs  Edge Costs • Variable Definition  Source • Variable Last Use  Sink 2005 International Symposium on Code Generation and Optimization

14. Solving an MCNF • Integer solution NP-complete • Use standard IP solvers • commercial solvers (CPLEX) are impressive • Exploit structure of problem • variety of MCNF specific solvers • empirically faster than IP solvers • Lagrangian Relaxation technique 2005 International Symposium on Code Generation and Optimization

15. b a 1 0+1 b a b a 1 0 with price, solution to single commodity flow can be solution to multicommodity flow b a Lagrangian Relaxation: Intuition • Relaxes the hard constraints • only have to solve single commodity flow • Combines easy subproblems using a Lagrangian multiplier • an additional price on each edge Example: edges have unit capacity 2005 International Symposium on Code Generation and Optimization

16. Solution Procedure • Compute prices using iterative subgradient optimization • converge to optimal prices • At each iteration, greedily construct a feasible solution using current prices • allocate most expensive vars first • can always find an allocation 2005 International Symposium on Code Generation and Optimization

17. Solution Procedure • Advantages • have feasible solution at each step • iterative nature  progressive • Lagrangian relaxation theory provides means for computing a lower bound • Can compute optimality bound • Disadvantages • No guarantee of optimality of solution 2005 International Symposium on Code Generation and Optimization

18. Evaluation • Replace gcc’s local allocator • Optimize for code size • easy to statically evaluate • Evaluate on MediaBench, MiBench, SpecInt95, SpecInt2000 • consider only blocks where local allocation is interesting (enough variables to spill) 2005 International Symposium on Code Generation and Optimization

19. Behavior of Solver 2005 International Symposium on Code Generation and Optimization

20. Proven Optimality 2005 International Symposium on Code Generation and Optimization

21. Comprehensive Results artifact of interaction with gcc 2005 International Symposium on Code Generation and Optimization

22. :-( Progressive Nature 2005 International Symposium on Code Generation and Optimization

23. Contributions • New MCNF model for register allocation • expressive, can model irregular architectures • can be solved using conventional ILP solvers • Progressive solution procedure • decent initial solution • maintains feasible solution • improves solution over time • no optimality guarantees Progressive 2005 International Symposium on Code Generation and Optimization