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

[Zino Benaissa]

Thanks Chad missed the *you* J

 

Jacob, 

 

First experiment:   Tried this over the course of development.  I observed
code size and performance regressions.  Only a small subset of Thumb 2
instructions can be encode in 16-bit.  We want to reserve R0-R7  only for
these instructions. My findings precision is important. 

 

Second experiment:  I have a concern of weakening the spill weight from
introducing the spills in hot blocks. Again this approach is indiscriminate
in assigning R0-R7 to instructions that will be encoded in 32-bits anyway. I
am still interested in giving it a try.  

 

-Zino 

 

From: Chad Rosier [mailto:mcrosier at apple.com] 
Sent: Tuesday, January 24, 2012 10:25 AM
To: Zino Benaissa
Cc: 'Jakob Stoklund Olesen'; 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

 

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/a616fbb7/attachment.html>