[PATCH 1/3] [PBQP] Tweak spill costs and coalescing benefits

Arnaud A. de Grandmaison arnaud.degrandmaison at arm.com
Tue Nov 4 12:25:40 PST 2014


Hi Lang,

 

I will go ahead and commit it as it definitely is an improvement --- in the current situation.

 

Whichever of  the spill placement or cost model  comes first will re-work those estimates.

 

Cheers,

Arnaud

 

From: Lang Hames [mailto:lhames at gmail.com] 
Sent: 04 November 2014 19:35
To: Arnaud De Grandmaison
Cc: Commit Messages and Patches for LLVM
Subject: Re: [PATCH 1/3] [PBQP] Tweak spill costs and coalescing benefits

 

Hi Arnaud,

 

Sorry for the delay. It has been a while time since I looked at the spill cost estimation code so I had to think about this a bit.

 

It looks like this code has no impact on greedy, so if you have measured an improvement in PBQP's allocations with this patch I'm happy for it to go in.

 

That said, I hope to come back soon and re-work these estimates to use a more consistent model. Ideally everything should be either estimated cycles of overhead (when compiling for speed) or estimated code-size overhead (when compiling for size). As you mentioned, this will all have to change when we fix the spill placement, so that might be a good time to revisit this.

 

Cheers,

Lang.

 

 

On Wed, Oct 22, 2014 at 6:24 AM, Arnaud A. de Grandmaison <arnaud.degrandmaison at arm.com> wrote:

Hi Lang,

 

Could you please review the attached patch ? This is the first out of three.

 

This patch improves how the different costs (register, interference, spill

and coalescing) relates together. The assumption is now that:

- coalescing (or any other "side effect" of reg alloc) is negative, and

   instead of being derived from a spill cost, they use the block

   frequency info.

- spill costs are in the [MinSpillCost:+inf( range

- register or interference costs are in [0.0:MinSpillCost( or +inf

 

The current MinSpillCost is set to 10.0, which is a random value high

enough that the current constraint builders do not need to worry about

when settings costs. It would however be worth adding a normalization

step for register and interference costs as the last step in the

constraint builder chain to ensure they are not greater than SpillMinCost

(unless this has some sense for some architectures). This would work well

with the current builder pipeline, where all costs are tweaked relatively

to each other’s, but could grow above MinSpillCost if the pipeline is

deep enough.

 

The current heuristic is tuned to depend rather on the number of uses of

a live interval rather than a density of uses, as used by the greedy

allocator. This heuristic provides a few percent improvement on a number

of benchmarks (eembc, spec, ...) and will definitely need to change once

spill placement is implemented: the current spill placement is really

inefficient, so making the cost proportional to the number of use is a

clear win.

 

This is the only patch in this PBQP improvement serie without a testcase

because this patch widely changes allocation, and it is hard to isolate simple and

meaningful testcases for it. The 2 following patches, which are addressing specific

areas of the allocator have a testcase.

 

Cheers,

--

Arnaud A. de Grandmaison

 

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


More information about the llvm-commits mailing list