[LLVMdev] Heads up! New SROA implementation is going on-by-default today!
baldrick at free.fr
Sun Sep 23 01:10:35 PDT 2012
> 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
> 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?
> 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.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev