<div dir="ltr"><div><div><span class="im">> If I understand this correctly, this will cause us
 to potentially generate wider vectors than we have underlying vector 
registers...<br><br></span></div><span class="im">This reminded me of a question I asked on the dev list a few weeks ago related to this bug:<br></span></div><div><span class="im"><a href="https://llvm.org/bugs/show_bug.cgi?id=20225">https://llvm.org/bugs/show_bug.cgi?id=20225</a><br><br></span></div><div><span class="im">One of the conclusions I came to was:<br>"The loop vectorizer shouldn't be so eager to generate a larger-than-legal type."<br></span></div><div><span class="im"><br></span></div><span class="im">I don't think there's been much effort trying to optimize super-wide shuffles.<br></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 11, 2015 at 10:51 PM, Nadav Rotem <span dir="ltr"><<a href="mailto:nrotem@apple.com" target="_blank">nrotem@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Apr 11, 2015, at 6:41 PM, <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> wrote:<br>
><br>
> [+Arnold, Nadav,Chandler]<br>
<br>
The loop vectorizer chooses a vectorization factor using a cost model and we stop the search at the widest type to limit cross-register shuffles. It is very difficult to model the performance impact of cross-register shuffles (both the quality of the shuffles that we generate and the performance impact of using multiple registers on register pressure).<br>
<br>
 Using the narrowest element type would increase the in-register utilization but decrease the utilization of execution units due to unrolling, so I am not sure what we are gaining here (except for extra shuffles).<br>
<span class=""><br>
><br>
> If I understand this correctly, this will cause us to potentially generate wider vectors than we have underlying vector registers, and I think that, generically, this makes sense. Now that our X86 shuffle handling is sane, the splitting of wide vectors, and shuffling that you get from vector extends/truncates is hopefully not too bad. Other opinions?<br>
><br>
> Did you see any performance changes on the test suite?<br>
><br>
> We might need to update the register-pressure heuristic (LoopVectorizationCostModel::calculateRegisterUsage()) to understand that very-wide vectors use multiple vector registers.<br>
<br>
</span>I agree.  Additionally, I think that we should rewrite this code. I made the mistake of calculating register pressure by scanning the code forward (start to end) instead of backwards, which made the code unnecessarily complicated (liveness should be calculated by scanning the basic block backwards).<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> <a href="http://reviews.llvm.org/D8943" target="_blank">http://reviews.llvm.org/D8943</a><br>
><br>
> EMAIL PREFERENCES<br>
>  <a href="http://reviews.llvm.org/settings/panel/emailpreferences/" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
><br>
><br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>