See <a href="http://llvm.org/PR18773">http://llvm.org/PR18773</a> for details now that I have a concrete test case.<br><br>It seems the problem is actually eliminating dead stores. For some reason this is sensitive to whether we sink the load out of the loop?!?! No idea why yet, will shift to using the bug to track this.<br>
<div>On Fri Feb 07 2014 at 6:33:44 PM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, fun story.<br><br>LICM is actually getting *more* powerful with this revision. Which causes a load to be sunk out of a loop in the second run of the pass pipeline. So why does that slow everything down?<div><br></div>
<div>Because the backend then duplicates the load back into the loop. Before LICM got better, there was a load before the loop and it just sat in a register. Afterward, the backend loaded it on each trip.</div><div><br></div>
<div>I almost have this nicely reduced to a reasonably small IR program that *really* highlights the performance impact of this transformation in the backend. I'll then work on a minimal test case that triggers the bad behavior in the backend. All of this should get filed as a PR against the x86 backend, but this is not a bug in r200067, or even a bug "uncovered" by that commit. This badness has been happening in *many* places for a long time, we just never had a test case which showed us one case where it used to *not* happen (by accident) and now does with a simple A/B comparison.</div>
<br><div>On Fri Feb 07 2014 at 2:06:52 PM, Gerolf Hoflehner <<a href="mailto:ghoflehner@apple.com" target="_blank">ghoflehner@apple.com</a>> wrote:</div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div style="margin:0px;font-size:18px;font-family:Menlo"><br></div><div style="margin:0px;font-size:18px;font-family:Menlo">The key option is -flto. Just O3 does not show the regression.</div>
<div style="margin:0px;font-size:18px;font-family:Menlo"><br></div><div style="margin:0px;font-size:18px;font-family:Menlo">Compiler version:</div><div style="margin:0px;font-size:18px;font-family:Menlo">/Users/ghoflehner/dev/regress_<u></u>builds/build/Debug+Asserts/<u></u>bin/clang++ -v</div>
<div style="margin:0px;font-size:18px;font-family:Menlo">clang version 3.5 (trunk 199970) (llvm/trunk 200067)</div><div style="margin:0px;font-size:18px;font-family:Menlo">Target: x86_64-apple-darwin13.1.0</div><div style="margin:0px;font-size:18px;font-family:Menlo">
Thread model: posix</div><div style="margin:0px;font-size:18px;font-family:Menlo"><br></div><div style="margin:0px;font-size:18px;font-family:Menlo">Options:</div><div style="margin:0px;font-size:18px;font-family:Menlo"><div style="margin:0px">
$CCROOT/bin/clang++ -I/Users/ghoflehner/dev/test_<u></u>builds/test-2014-01-28_04-36-<u></u>58/SingleSource/Benchmarks/<u></u>Adobe-C++ -I/Users/ghoflehner/dev/llvm-<u></u>test-suite/SingleSource/<u></u>Benchmarks/Adobe-C++ -I/Users/ghoflehner/dev/llvm-<u></u>test-suite/include -I../../../include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -DNDEBUG  -O3 -Wno-implicit-function-<u></u>declaration -Wno-incompatible-pointer-<u></u>types -flto -isysroot /Applications/Xcode.app/<u></u>Contents/Developer/Platforms/<u></u>MacOSX.platform/Developer/<u></u>SDKs/MacOSX10.9.sdk -mavx  -m64 -fomit-frame-pointer -mdynamic-no-pic -c /Users/ghoflehner/dev/llvm-<u></u>test-suite/SingleSource/<u></u>Benchmarks/Adobe-C++/loop_<u></u>unroll.cpp -o loop_unroll.o</div>
<div style="margin:0px">env DYLD_LIBRARY_PATH=$CCROOT/lib $CCROOT/bin/clang++ -o loop_unroll.simple loop_unroll.o -lm -lstdc++  -Wno-implicit-function-<u></u>declaration -Wno-incompatible-pointer-<u></u>types -isysroot /Applications/Xcode.app/<u></u>Contents/Developer/Platforms/<u></u>MacOSX.platform/Developer/<u></u>SDKs/MacOSX10.9.sdk -mavx -m64 -fomit-frame-pointer -mdynamic-no-pic</div>
<div><br></div></div></div></div><div style="word-wrap:break-word"><div><div><br></div><div><div><div>On Feb 7, 2014, at 1:33 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:</div>
<br><blockquote type="cite">I've diffed the IR at -O3 before and after r200067 and it is identical other than SSA value names that are minutely different.<br><div><br></div><div>I think i'll need before/after IR or an exact commandline to produce the exact same result you're seeing to make much progress here.</div>

<br><div>On Fri Feb 07 2014 at 1:16:35 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:</div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

So this doesn't reproduce for me at all when I just compile and loop_unroll.cpp from the test suite for x86 (sandybridge). Not really sure what all is required to observe this slowdown.<br><div><br></div><div>I've also checked and we have no interesting benchmark regressions on our internal benchmarks with that revision... Really weird.</div>

<div><br></div><div>Can you provide before/after bitcode? File a bug as well to track it if its this severe?</div><br><div>On Fri Feb 07 2014 at 12:32:34 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:</div>

<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's really weird because the public performance bots don't show this regression:<br><br><a href="http://llvm.org/perf/db_default/v4/nts/21277" target="_blank">http://llvm.org/perf/db_<u></u>defaul<u></u>t/v4/nts/21277</a><br>

<div><br></div><div>It would be really nice to get the stuff that people have hard requirements on posted to the LNT dashboard...</div><div><br></div><div>It's also particularly weird because this shouldn't really have changed the way LICM works. Looking into it though...</div>

<br><div>On Thu Feb 06 2014 at 11:19:21 AM, Gerolf Hoflehner <<a href="mailto:ghoflehner@apple.com" target="_blank">ghoflehner@apple.com</a>> wrote:</div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word">Hi Chandler<div><br></div><div>your commit seems to cause a major regression (>20%)  on loop_unroll and other benchmarks as well. This is ( at least)  on x86 under -O3 -flto and seems to be due to the loss of LICM. Please take a look.</div>

<div><br></div><div>Cheers</div><div>Gerolf</div><div><br></div><div><div style="margin:0px;font-size:18px;font-family:Menlo">------------------------------<u></u><u></u><u></u>------------------------------<u></u><u></u><u></u>------------</div>

<div style="margin:0px;font-size:18px;font-family:Menlo">r200067 | chandlerc | 2014-01-24 20:07:24 -0800 (Fri, 24 Jan 2014) | 44 lines</div><div style="margin:0px;font-size:18px;font-family:Menlo;min-height:21px"><br></div>

<div style="margin:0px;font-size:18px;font-family:Menlo">[LPM] Make LCSSA a utility with a FunctionPass that applies it to all</div><div style="margin:0px;font-size:18px;font-family:Menlo">the loops in a function, and teach LICM to work in the presance of</div>

<div style="margin:0px;font-size:18px;font-family:Menlo">LCSSA.</div></div><div><br></div></div></blockquote></blockquote></blockquote>
</blockquote></div><br></div></div></div></blockquote></blockquote>