<div dir="ltr">Okay. I've looked at this and it's looks like in an issue with SelectionDAG's Alias Analysis. We were only doing Base-Offset analysis and not Base-Index-Offset checking like we do elsewhere in SelectionDAG which causes us to not be able to parallelize these stores. This seems pretty clearly separate so I'm going to spin this off into a new patch. </div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 11, 2017 at 2:43 PM, Aditya Nandakumar <span dir="ltr"><<a href="mailto:aditya_nandakumar@apple.com" target="_blank">aditya_nandakumar@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Managed to figure out what was different with x86_64 backend (and why it was not reproducing with the same test case).<br>
<br>
The following test case should reproduce the issue of failing merging.<br>
<br>
bin/llc -mtriple=x86_64-apple-darwin -o - test.ll  -disable-lsr<br>
 <br><br>
<br>
I haven’t looked into why lsr hides the issue though.<br>
<br>
Aditya<br>
> On Apr 11, 2017, at 10:25 AM, Nirav Davé <<a href="mailto:niravd@google.com">niravd@google.com</a>> wrote:<br>
><br>
> Hmm. This is disconcerting. It looks pretty clear that t50 improved it's chain from t18 to t0, but findBetterNeighborChains should be doing fixing all of the upper chains improved to t0 simultaneously. This is likely  be a nontrivial compiler slowdown. Would it possible to get the llvm code for this case?<br>
> ​<br>
<br>
<br></blockquote></div><br></div>