<div dir="ltr">Hi,<br><br>Your first example is similar to the strided loops that Hao is working on vectorizing with his indexed load intrinsics. We have dedicated instructions for these in NEON, but they can be synthesized with a load+unzip / zip+store, which I assume is what icc is doing.<div><br></div><div>If I'm right, this is in progress.</div><div><br></div><div>Cheers,</div><div><br></div><div>James</div></div><br><div class="gmail_quote">On Wed, 22 Apr 2015 at 12:57 Vaivaswatha N <<a href="mailto:vaivaswatha@yahoo.co.in">vaivaswatha@yahoo.co.in</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:Courier New,courier,monaco,monospace,sans-serif;font-size:10px"><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif" size="3">>have you tried writing code for that, and confirmed that it's actually better than just straight loop?</font></div></div><div><div style="color:#000;background-color:#fff;font-family:Courier New,courier,monaco,monospace,sans-serif;font-size:10px"><div dir="ltr"><span><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif"><font size="3">The same loop gets vectorized on icc and runs faster hence.</font></font></span></div><div dir="ltr"><span><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif"><font size="3"><br></font></font></span></div><div dir="ltr"><span><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif"><font size="3">Also, </font></font></span><span><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif"><font size="3">as an experiment, I tried forcing <font face="Courier New, courier, monaco, monospace, sans-serif">isStridedPtr</font>() to return
true. The vectorizer proceeds to vectorize the loop, but does a
poor job. Instead of using vector Load/Store instructions and
packing/unpacking, it uses scalar Load/Stores instructions and
packs them for the arithmetic operations. Note that without the pragma, the cost model does advice against the vectorization. My reason for forcing vectorization was that it did well on icc.</font></font></span></div><div dir="ltr"><br><span></span></div><div dir="ltr"><span><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif"><font size="3">On icc, I tried the above loop without any pragmas and saw that the loop was vectorized. Also using the pragma "novector" resulted in the loop not being vectorized. With vectorization, performance was better. <br></font></font></span></div><div dir="ltr"><span><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif"><font size="3"><br></font></font></span></div><div dir="ltr"><span><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif"><font size="3">Thanks,<br></font></font></span></div></div></div><div><div style="color:#000;background-color:#fff;font-family:Courier New,courier,monaco,monospace,sans-serif;font-size:10px"><div><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif" size="3"> </font></div><div><div><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif" size="3">- Vaivaswatha</font></div></div></div></div><div><div style="color:#000;background-color:#fff;font-family:Courier New,courier,monaco,monospace,sans-serif;font-size:10px"><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif" size="3"> </font><br><div><br><br></div><div style="display:block"> <div style="font-family:Courier New,courier,monaco,monospace,sans-serif;font-size:10px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif;font-size:16px"> <div dir="ltr"> <font face="Arial" size="2"> On Wednesday, 22 April 2015 4:46 PM, mats petersson <<a href="mailto:mats@planetcatfish.com" target="_blank">mats@planetcatfish.com</a>> wrote:<br> </font> </div> <br><br> <div>In your first case, I fail to see what the obvious vectorisation would<br clear="none">be - you are reading one and writing one of the every other element -<br clear="none">that is not very easy to made into vectorized operatioons - have you<br clear="none">tried writing code for that, and confirmed that it's actually better<br clear="none">than just straight loop?<br clear="none"><br clear="none">--<br clear="none">Mats<br clear="none"><div><br clear="none">On 22 April 2015 at 12:01, Vaivaswatha N <<a shape="rect" href="mailto:vaivaswatha@yahoo.co.in" target="_blank">vaivaswatha@yahoo.co.in</a>> wrote:<br clear="none">> Hi,<br clear="none">><br clear="none">> I am trying to understand the limitations of the current vectorizer, and<br clear="none">> came upon these test cases that fail to get vectorized.<br clear="none">><br clear="none">> 1. loop1 below (note the increment by 2) fails to get vectorized because the<br clear="none">> access a[j+1] is considered to wrap around (the corresponding SCEV doesn't<br clear="none">> have nsw/nuw set) and hence isStridedPtr() in LoopAccessAnalysis.cpp return<br clear="none">> false.<br clear="none">><br clear="none">> #define SIZE 100000<br clear="none">> void loop1 (float a[SIZE])<br clear="none">> {<br clear="none">> long t, j;<br clear="none">> float cc = 23, dd = 34, ee = 233;<br clear="none">> #pragma clang loop vectorize(enable)<br clear="none">> for (j = 1; j < SIZE-1; j += 2) {<br clear="none">> float x;<br clear="none">> x = a[j+1] + ee;<br clear="none">> x = x / dd;<br clear="none">> x = (cc + x) / dd;<br clear="none">> a[j] = x + 2 ;<br clear="none">> }<br clear="none">> }<br clear="none">><br clear="none">> 2. Of the two loops below, the loop "works" gets vectorized, while the loop<br clear="none">> "fails" does not get vectorized.<br clear="none">> #define SIZE 10000<br clear="none">> int a[SIZE+4] = {};<br clear="none">> void works(unsigned long m, unsigned long n)<br clear="none">> {<br clear="none">> long j;<br clear="none">> // SCEV can compute the exit value for this loop<br clear="none">> for (j = m; j < n+1; j += 1) {<br clear="none">> a[j] = a[j+1] + 2;<br clear="none">> }<br clear="none">> }<br clear="none">> void fails(unsigned long m, unsigned long n)<br clear="none">> {<br clear="none">> long j;<br clear="none">> // SCEV cannot compute the exit value for this loop<br clear="none">> for (j = m; j <= n; j += 1) {<br clear="none">> a[j] = a[j+1] + 2;<br clear="none">> }<br clear="none">> }<br clear="none">><br clear="none">> The only difference between the two loops is the loop exit condition, both<br clear="none">> semantically same. Scalar Evolution is unable to determine the exit value of<br clear="none">> the second loop, leading to the vectorizer failing to vectorize. It seemed<br clear="none">> to me that this is due to ScalarEvolution::SimplifyICmpOperands failing to<br clear="none">> canonicalize the corresponding ICMP_ULE instruction.<br clear="none">><br clear="none">> Thanks,<br clear="none">><br clear="none">> - Vaivaswatha</div><br clear="none">><br clear="none">><br clear="none">> _______________________________________________<br clear="none">> LLVM Developers mailing list<br clear="none">> <a shape="rect" href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a shape="rect" href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br clear="none">> <a shape="rect" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><div><br clear="none">><br clear="none"></div><br><br></div> </div> </div> </div></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div>