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

[Jakob Stoklund Olesen]

On Jan 23, 2012, at 5:11 PM, Zino Benaissa wrote:

> Description:
> This contribution extends LLVM greedy Register Allocator to optimize for code size when LLVM compiler targets ARM Thumb 2 instruction set. This heuristic favors assigning register R0 through R7 to operands used in instruction that can be encoded in 16 bits (16-bit is allowed only if R0-7 are used). Operands that appear most frequently in a function (and in instructions that qualify) get R0-7 register.
> This heuristic is turned on by default and has impact on generated code only if -mthumb compiler switch is used. To turn this heuristic off use -disable-favor-r0-7 feature flag.
>  
> This patch modifies: 
> 1) The LLVM greedy register allocator located in LLVM/CodeGen directory: To add the new code size heuristic.
> 2) The ARM-specific flies located in LLVM/Target/ARM directory: To add the function that determines which instruction can be encoded in 16-bits and a fix to enable the compiler to emit CMN instruction in 16-bits encoding. 
> 3) The LLVM test suite: fix test/CodeGen/Thumb2/thumb2-cmn.ll test.

Hi Zino,

Thanks for working on this interesting patch.

Please submit the CMN-related changes as an independent patch.

If you don't mind, I would like you to run a couple of experiments to better understand why this change improves some benchmarks.

First of all, is the regHasSizeImpact() hook necessary? Do you get significantly different results if you pretend this function always returns 2?

Second, what happens if you use a 'flatter' spill weight? Instead of your patch, in LiveIntervals::getSpillWeight replace this:

  float lc = std::pow(1 + (100.0 / (loopDepth + 10)), (double)loopDepth);

with this:

  float lc = std::pow(1 + (100.0 / (loopDepth + 10))/5, (double)loopDepth);

And in CalcSpillWeights.h, replace the number 25 in normalizeSpillWeight() with 250. Does that give you similar results?

Thanks,
/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120123/fc5f82d1/attachment.html>