<div dir="ltr"><div class="gmail_quote">On Tue, Apr 14, 2015 at 8:35 AM James Molloy <<a href="mailto:james@jamesmolloy.co.uk">james@jamesmolloy.co.uk</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Sanjay,<br><br>Actually Chandler had the opposite opinion, and I at least have been pushing the ARM backends into q shape that they can deal gracefully with oversize vectors. The work I've done should affect all backends equally, actually. <br></blockquote><div><br></div><div>Yes, and I'm really excited about this.</div><div><br></div><div>I think oversized vectors, provided they're formed reasonably carefully, are a good way to express the generic "widening" of operations.</div><div><br></div><div>At some point, I think we should be able to remove the unrolling logic from the loop vectorizer and replace it with over-wide vectors, but that requires truly superb lowering.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>I'd be interested in what others' opinions are here, because I've heard both arguments and both seem valid to me!<br><br>Cheers,<br><br>James<br><div class="gmail_quote">On Tue, 14 Apr 2015 at 05:33, Sanjay Patel <<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><span>> 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>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><a href="https://llvm.org/bugs/show_bug.cgi?id=20225" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=20225</a><br><br></span></div><div><span>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><br></span></div><span>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" target="_blank">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><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><div><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" target="_blank">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>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">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>
</blockquote></div>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">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>
</blockquote></div></div>