[llvm-commits] Tuning LLVM Greedy Register Allocator to optimize for code size when targeting ARM Thumb 2 instruction set

[Zino Benaissa]

Couple more thing, As mentioned Both runtime and code size are improved. One
peep that got triggered more is:

cmp r0, 0
beq  L

is peeped to:

cbz r0  (compared and branch) 

while r8-r13 stay as is: 

cmp r8, 0
beq L 


Last but not least, thank you for in-depth review of this work. 

Cheers, 

-Zino 

-----Original Message-----
From: Zino Benaissa [mailto:zinob at codeaurora.org] 
Sent: Wednesday, January 25, 2012 8:02 PM
To: 'Jakob Stoklund Olesen'
Cc: 'rajav at codeaurora.org'; 'llvm-commits at cs.uiuc.edu'
Subject: RE: [llvm-commits] Tuning LLVM Greedy Register Allocator to
optimize for code size when targeting ARM Thumb 2 instruction set



>> The way to look at it is the other way:
>> 1.       If the offset of load/store is too large then don't bother
assigning R0-7
>> 2.       If both operands of ADD are not kill then don't bother assigning
R0-7
>> 3.       If immediate of ADD is too large don't bother assigning R0-7
>> .
>> The goal is to eliminate  as much as possible candidates that compete for
R0-R7 so that the RA  does a better assignment of R0-R7 (which ultimately
increases 16-bits encoding).
>> Returning 2 fails to do this. You may  as well return 0 instead of 2 J.

>Does this negative bias mean that VirtReg.bytes is 0 for most virtual
registers? How > many get VirtReg.bytes > 0?

Of course it varies and depends on the compiled code. I have seen that
VirtReg.bytes =0 (or close) while this VirtReg occurs frequently in the
function (Which in this case their weight is high). At the same  I have seen
Candidate that have a very high VirtReg.byte and (they were getting a
costPerUse register before this heuristic). Some EEMBC benchmarks shrank
with > 5% and are example of this. 

>As I am reading your changes to the eviction policy, you are completely
replacing >spill weights with a code size metric for live ranges with
Virteg.bytes > 0. Is that >the intention?

It depends why the eviction is invoked. Currently there are three reasons
for invoking eviction: enabling coalescing, preventing spill/split,
preventing a costPerUse register. Note all these evections where already put
in place before my heuristic.
 1) Both for coalescing or for preventing split/spill: VirtReg.bytes=0 and
the heuristic is ignored and only the pair <hint,weight> is considered.
Whatever were put in place is still managing these type of evictions. 
 2) This heuristic is ON only when a candidate gets a register that has a
CostPerUse. In this case, When the RA attempts to trade it for a register
with no cost, Now with this heuristic it has a metric to evaluate whether
there is a trade worth evicting for. 
  

-Zino