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

[Chandler Carruth]

On Mon, Sep 24, 2012 at 3:41 AM, David Tweed <david.tweed at arm.com> wrote:

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

Thanks for letting me know!

I know that there is one serious bug that would impact in BE system. I
should have that fixed today, along with a crasher. I would appreciate help
tracking down any issues once the one I know of is fixed though.

If this is cause problems for anyone, you can disable it with a flag, or we
can temporarily turn it back off. I'm expecting to have most of the issues
folks have reported fixed today though.


> ****
>
> ** **
>
>     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****
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120924/4837e2fd/attachment.html>