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

[Chad Rosier]

Hi Zino,
One comments below.

On Jan 23, 2012, at 9:46 PM, Zino Benaissa wrote:

> Hi Jacob,
>  
> Thanks for quick feedback.   See my  comments  below,
>  
> Cheers,
>  
> Zino
> From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] 
> Sent: Monday, January 23, 2012 7:18 PM
> To: Zino Benaissa
> Cc: llvm-commits at cs.uiuc.edu; rajav at codeaurora.org
> Subject: Re: [llvm-commits] Tuning LLVM Greedy Register Allocator to optimize for code size when targeting ARM Thumb 2 instruction set
>  
>  
> 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.
>  
> Ø    Sure, I can do that.
>  
> If you don't mind, I would like you to run a couple of experiments to better understand why this change improves some benchmarks.
>  
> Ø    Sure,  please let me know what you find.

Just to be clear, I believe Jakob was suggesting *you* run the experiments.

 Chad

>  
> First of all, is the regHasSizeImpact() hook necessary? Do you get significantly different results if you pretend this function always returns 2?
>  
> Ø    For my experiments,  precision is quite important to maximize code size gains.
>  
> 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?
>  
> Ø    I did not try this experiment.  However  by doing so, aren’t you increasing chances for spills to be inserted in hot blocks (like inner loops)?
>  
> Thanks,
> /jakob
>  
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

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