llvm dev - Sep 2012 - [LLVMdev] Heads up! New SROA implementation is going on-by-default today!

After a lot of testing and help from Duncan, Benjamin, Joerg and others, I
think the new SROA is ready for some broader testing. I've fixed all the
crashers and miscompiles that Duncan and Joerg have been able to find
(although I'm sure there are a few left I'll tackle when there are
reports), and the LNT numbers look *really* good. Here is the latest LNT
run we got by flipping it on and back off:

http://llvm.org/perf/db_default/v4/nts/3963

Most of this is very, very green. There are three somewhat worrisome
regressions in execution time:

1) sse_expandfft -- when I build this, the binaries have no differences
before and after
2) sse_stepfft -- ditto
3) matmul_f64_4x4 -- this one is interesting

The last one represents the only real regressions I expect to see with the
new pass. There is a helpful indicator about what caused it: the compile
time *improved* by 44%!!! This is because the benchmark was tickling the
bad behavior of the old SROA pass that inspired a lot of this work, and was
building massive bit vectors to store integer arrays. The new pass doesn't
do that, produces the exact IR desired from this benchmark, and speeds up
compilation by a huge factor.

Unfortunately, sometimes having all the integers be stuffed into a big
bitvector and lowered during legalization papered over problems in the
register allocator (they look like spill placement to me? Haven't dug too
deeply) that are now being exposed. That's responsible for the 7%
regression in matmul.

Just ping me if this causes anyone problems! You can also temporarily
disable it by passing '-mllvm -use-new-sroa=false' to Clang.
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120922/d6fdc418/attachment.html>

Hi Chandler,
> After a lot of testing and help from Duncan, Benjamin, Joerg and others, I
think
> the new SROA is ready for some broader testing. I've fixed all the
crashers and
> miscompiles that Duncan and Joerg have been able to find (although I'm
sure
> there are a few left I'll tackle when there are reports), and the LNT
numbers
> look *really* good. Here is the latest LNT run we got by flipping it on and
back
> off:
>
> http://llvm.org/perf/db_default/v4/nts/3963
>
> Most of this is very, very green. There are three somewhat worrisome
regressions
> in execution time:
>
> 1) sse_expandfft -- when I build this, the binaries have no differences
before
> and after
> 2) sse_stepfft -- ditto
presumably the binaries differ on the LNT machine.  Maybe you should try to get
preprocessed source from that machine?

Ciao, Duncan.
> 3) matmul_f64_4x4 -- this one is interesting
>
> The last one represents the only real regressions I expect to see with the
new
> pass. There is a helpful indicator about what caused it: the compile time
> *improved* by 44%!!! This is because the benchmark was tickling the bad
behavior
> of the old SROA pass that inspired a lot of this work, and was building
massive
> bit vectors to store integer arrays. The new pass doesn't do that,
produces the
> exact IR desired from this benchmark, and speeds up compilation by a huge
factor.
>
> Unfortunately, sometimes having all the integers be stuffed into a big
bitvector
> and lowered during legalization papered over problems in the register
allocator
> (they look like spill placement to me? Haven't dug too deeply) that are
now
> being exposed. That's responsible for the 7% regression in matmul.
>
> Just ping me if this causes anyone problems! You can also temporarily
disable it
> by passing '-mllvm -use-new-sroa=false' to Clang.
> -Chandler
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Just a note that the following new regressions have started to show up on
ARM/Linux:

 

    LLVM :: Bitcode/blockaddress.ll

    LLVM :: CodeGen/ARM/fast-isel.ll

    LLVM :: CodeGen/X86/atomic16.ll

    LLVM :: MC/ARM/arm-shift-encoding.s

    LLVM :: MC/ARM/thumb-shift-encoding.s

    LLVM :: MC/COFF/global_ctors_dtors.ll

    LLVM :: Transforms/InstCombine/div-shift.ll

    LLVM :: Transforms/LoopIdiom/non-canonical-loop.ll

    LLVM :: Transforms/SROA/basictest.ll

    LLVM :: Transforms/SROA/phi-and-select.ll

 

I haven't yet looked at them in detail, and obviously on the last two
clearly involve SROA, but given that these tests haven't started to fail (or
at least been fixed before I noticed) on my x86 machine I thought it worth
reporting.

 

Cheers,

David

 

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Chandler Carruth
Sent: 22 September 2012 20:09
To: LLVM Developers Mailing List
Subject: [LLVMdev] Heads up! New SROA implementation is going on-by-default
today!

 

After a lot of testing and help from Duncan, Benjamin, Joerg and others, I think
the new SROA is ready for some broader testing. I've fixed all the crashers
and miscompiles that Duncan and Joerg have been able to find (although I'm
sure there are a few left I'll tackle when there are reports), and the LNT
numbers look *really* good. Here is the latest LNT run we got by flipping it on
and back off:

 

http://llvm.org/perf/db_default/v4/nts/3963

 

Most of this is very, very green. There are three somewhat worrisome regressions
in execution time:

 

1) sse_expandfft -- when I build this, the binaries have no differences before
and after

2) sse_stepfft -- ditto

3) matmul_f64_4x4 -- this one is interesting

 

The last one represents the only real regressions I expect to see with the new
pass. There is a helpful indicator about what caused it: the compile time
*improved* by 44%!!! This is because the benchmark was tickling the bad behavior
of the old SROA pass that inspired a lot of this work, and was building massive
bit vectors to store integer arrays. The new pass doesn't do that, produces
the exact IR desired from this benchmark, and speeds up compilation by a huge
factor.

 

Unfortunately, sometimes having all the integers be stuffed into a big bitvector
and lowered during legalization papered over problems in the register allocator
(they look like spill placement to me? Haven't dug too deeply) that are now
being exposed. That's responsible for the 7% regression in matmul.

 

Just ping me if this causes anyone problems! You can also temporarily disable it
by passing '-mllvm -use-new-sroa=false' to Clang.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120924/3f02976a/attachment.html>