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

[Lang Hames]

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