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

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

3. 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

4. 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

5. 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

6. 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

7. 2005 International Symposium on Code Generation and Optimization 7 Previous Work Method Models Irregular Features FastOptimal Graph Coloring Integer Programming [Goodwin and Wilken 96] [Kong and Wilken 98] [Fu and Wilken 2002] Separated IP [Appel and George 01] PBQP [Scholz and Eckstein 02] //

8. 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

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

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

11. 2005 International Symposium on Code Generation and Optimization 11 Modeling Spills and Moves int foo(int a, int b, int c) { a = a*b; return a/c; } a imul eaxedxecxmem b 1 eaxedxecxmem eaxedxecxmem c b 333 a idiv eaxedxecxmem c 1 eaxedxecxmem eaxedxecxmem

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

13. 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

14. 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

15. 2005 International Symposium on Code Generation and Optimization 15 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 a b a b 01 Example: edges have unit capacity a b a b 0+11 with price, solution to single commodity flow can be solution to multicommodity flow

16. 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

17. 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

18. 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)

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

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

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

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

23. 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