On 13.06.2013, at 19:12, Diego Novillo <dnovillo at google.com> wrote:
> On 2013-06-12 18:15 , Chandler Carruth wrote:
>>
>> On Wed, Jun 12, 2013 at 3:10 PM, Jakob Stoklund Olesen <stoklund at
2pi.dk> wrote:
>> It predates the block frequency interface. It just needs to be hooked
up, patches welcome. It would also be nice to remove the floating point
computations from the spill placement code.
>>
>> Cool, if Diego doesn't beat me to it, I may send you a patch as
that seems easy and obviously beneficial.
>
> Unless you're in a hurry, I'd rather tackle this one myself.
Particularly considering that I've no idea what you two are yapping about,
so it will be a good learning experience.
I didn't want to interfere with you in any way but I was working on this
just this week, though from a completely different background:
In zlib's longest_match() (which happens to contain the hottest loop in
deflate()) there's a loop with this layout:
do {
if (something) continue;
while (cond && cond && cond && cond && cond) {
}
} while (something_else);
The inner while loop is freezing cold. This is one of the cases where the
current estimation based on loop depth completely fails while the heuristics
BlockFrequency is based on get it right. With the old spill weights we spilled
parts of the "something_else" code above that had to be reloaded on
every iteration so we could keep more data of the inner loop in registers,
causing a huge slowdown.
I hacked up a patch and saw a whopping 5% improvement on deflate, bringing us a
lot closer to GCC on this code. Other benchmarks I tried so far looked neutral
or positive but sometimes I saw a large increase in spilling; bloating code
size, that needs to be figured out.
This patch only does the grunt work of getting the BlockFrequency analysis into
the spill placement code, it doesn't replace the use of floats in the
register allocator. It's possible that some of the downstream calculations
need an update to cope with the changed magnitude of the frequencies.
Do you want to take over this effort or should I poke more at it?
- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: block-frequency-spilling.patch
Type: application/octet-stream
Size: 23162 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130615/4d5b3577/attachment.obj>