Register Alloca.on Deconstructed. David Ryan Koes Seth Copen Goldstein

Transcription

1 Register Alloca.on Deconstructed David Ryan Koes Seth Copen Goldstein 12th Interna+onal Workshop on So3ware and Compilers for Embedded Systems April 24, 12009

2 Register Alloca:on Problem unbounded number of program variables v = 1 w = v + 3 x = w + v u = v t = u + x print(x); print(w); print(t); print(u); register allocator limited number of processor registers + slow memory eax ebx ecx edx esi edi esp ebp 2

3 Register Alloca:on Graph coloring Linear scan Op:mal frameworks Move elimina:on allocators 3

4 Register Alloca:on Graph coloring Linear scan Op:mal frameworks Move elimina:on allocators 3

5 Ques:ons What is the penalty of decomposing register alloca:on into individual components? What is the individual impact of each component on code quality? How far from op:mal are exis:ng heuris:cs? Our goal is to answer these ques.ons. An op:mal register alloca:on framework is used to empirically evaluate the importance of the components of register alloca:on, the impact of component integra:on, and the effec:veness of exis:ng heuris:cs. 4

6 Outline Mo:va:on Register Alloca:on Components Move Inser:on Coalescing Spilling Assignment Methodology Results Conclusion 5

7 Move Inser:on Addi:onal move instruc:ons can simplify assignment problem Can eliminate need to spill Does not directly improve code quality L1: write b read a write c read b write a read c branch L1 Live a a b c RA a a b c 6 move r0 -> r1

8 Move Inser:on Evalua:on full: move instruc:ons may be inserted at any program point limited: move instruc:ons may be inserted only at the entry and exit of basic blocks none: no register to register move instruc:ons are generated by the allocator 7

9 Coalescing Eliminate move instruc:ons by assigning each operand to the same loca:on Can be performed as separate pass lose ability to coalesce with physical registers lose ability to coalesce uncoalescables Pre alloc Coalescing Physical Reg Uncoalescable t1 t1 t2 t1 t2 t3 t3 t3 t3 t3 t3 r0 t1 t1 t2 t1 t2 t1 8

10 Coalescing Evalua:on integrated op.mal: move coalescing is solved op:mally as part of the complete register alloca:on problem integrated op.mal ignoring uncoalescable: the register allocator fully op:mizes only those move instruc:ons iden:fied as coalescable prior to register alloca:on separate op.mal: move coalescing is solved op:mally as a separate problem prior to alloca:on separate aggressive: a greedy heuris:c aggressively eliminates coalescable moves prior to register alloca:on none: no coalescing is performed 9

11 Spilling Can be performed as a separate pass spill variables to memory to meet register needs at each program point if move and swap inser:ons are allowed, assignment is now possible reg MAXLIVE #REG = 2 b c d 10 mem

12 Spilling Evalua:on integrated op.mal: spill code genera:on is solved op:mally as part of the complete register alloca:on problem separate op.mal: the spill code genera:on problem (reducing max liveness to meet register availability) is solved op:mally as a standalone problem separate heuris.c: the spill code genera:on problem is solved as a standalone problem using a heuris:c algorithm 11

13 Assignment assign physical register(s) to each variable at every program point may change assignment of variable by inser:ng move instruc:on if spilling and coalescing are performed separately, leaves assignment op:mizes for register preferences 12

14 Assignment Evalua:on integrated op.mal: assignment is solved op:mally as part of the complete register alloca:on problem graph heuris.c: a graph coloring based heuris:c is used to assign registers to the results of spill code genera:on; move instruc:ons may be inserted to improve colorability linear scan heuris.c: a linear scan based heuris:c is used to assign register to the results of spill code genera:on; move instruc:ons may be inserted to improve colorability 13

15 Methodology Implement op:mal register alloca:on framework in LLVM 2.4 Consider four target architectures and two code quality metrics CISC Fewer registers More registers RISC 14

16 Limita:ons Self selec:ng bias in results limited to those func:ons where an op:mal solu:on can be found in reasonable :meframe however, qualita:ve results do not appear to change as more :me is allowed for op:mal allocator Implement swap using memory loca:on Performance metric necessarily inexact (weighted sum of memory opera:ons) Evaluate performance only on desktop processors 15

17 Results: Code Size Evaluate subset of Mibench Consider all func:ons where op:mal solu:ons can be found in <10 minutes more than 70% coverage of func:ons Report code size increase rela:ve to fully op:mal (1.0 best possible result) 16

18 Results: Code Performance Evaluate subset of SPEC2006 Op:mize only cri:cal(>85% of running :me) func:ons Intel Core 2 Quad 2.4GHz Report geometric mean rela:ve to fully op:mal model Possible to do beier than op:mal due to limita:ons of metric 17

19 Move Inser:on: Code Size 18

20 Move Inser:on: Code Performance 19

21 Coalescing: Code Size 20

22 Coalescing: Code Performance 21

23 Spilling: Code Size 22

24 Spilling: Code Performance 23

25 Assignment: Code Size 24

26 Assignment: Code Performance 25

27 Heuris:cs: Code Size 26

28 Heuris:cs: Code Performance 27

29 Conclusions When targe:ng processor performance, new register allocator designs should focus on solving spill code op.miza.on as the coalescing, move inser:on, and register assignment problems are adequately solved using exis:ng heuris:cs. When targe:ng code size, new register allocator designs should focus on solving both the spill code op.miza.on and register assignment problems, possibly in an integrated framework. 28