[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