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

[Jakob Stoklund Olesen]

On Jan 24, 2012, at 11:24 AM, Zino Benaissa wrote:

> Yes, this is heuristic by definition it is a guess.

Nothing wrong with that.

> 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?

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?

/jakob