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

[Zino Benaissa]

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. 

 

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

 

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