<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">There were several patches (r278501 was the first) that fixed vector shift bugs. I don’t think the IR changes were intentional.</div><div class=""><br class=""></div><div class="">I’m not sure if it’s the right solution, but inserting an integral cast before the CK_VectorSplat cast in checkVectorShift makes IRGen emit the trunc before the splat.</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Mar 8, 2017, at 7:21 AM, Sanjay Patel via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">The regression for the reported case should be avoided after:<br class=""><a href="https://reviews.llvm.org/rL297232" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/rL297<wbr class="">232</a><br class=""><a href="https://reviews.llvm.org/rL297242" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/rL297<wbr class="">242</a><br class=""><a href="https://reviews.llvm.org/rL297280" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/<wbr class="">rL297280</a><br class=""><br class=""></div>It would still be good to understand if the clang change was intentional or if that was a side effect that can be limited.<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Feb 18, 2017 at 9:11 AM, Sanjay Patel <span dir="ltr" class=""><<a href="mailto:spatel@rotateright.com" target="_blank" class="">spatel@rotateright.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="">Yes, there is an IR difference between clang 3.9.1 and clang trunk before any IR transforms are done:<br class=""><a href="https://godbolt.org/g/FuBqIb" target="_blank" class="">https://godbolt.org/g/FuBqIb</a><br class=""><br class=""></div>We can't solve this problem (moving a trunc ahead of other vector ops) in general in IR because we take a conservative approach to vector transforms in IR. That means the burden for solving the general problem falls on the front-end or the back-end. If you can bisect to find the clang commit where this changed, that would be very helpful.<br class=""><br class="">However, I think we can handle a very specific case (a too fat splat) in IR in instcombine, and it will resolve this exact example. This will take a couple of patches to restore your example. Here's a proposal for the first one:<br class=""><a href="https://reviews.llvm.org/D30123" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D3012<wbr class="">3</a><br class=""><br class=""></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Feb 18, 2017 at 12:33 AM, Saurabh Verma <span dir="ltr" class=""><<a href="mailto:saurabh.verma@movidius.com" target="_blank" class="">saurabh.verma@movidius.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Thanks Sanjay. Interestingly for me, disable-llvm-optmzns did not make a difference in the way the shift was handled. Does the initial IR generated for you show this difference when the option is passed?<div class=""><br class=""></div><div class="">Best regards</div><span class="m_-8900007202819893423HOEnZb"><font color="#888888" class=""><div class="">Saurabh<br class=""><div class=""><br class=""></div></div></font></span></div><div class="m_-8900007202819893423HOEnZb"><div class="m_-8900007202819893423h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On 17 February 2017 at 19:03, Sanjay Patel <span dir="ltr" class=""><<a href="mailto:spatel@rotateright.com" target="_blank" class="">spatel@rotateright.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class=""><div class="">I think this is caused by a front-end change (cc'ing clang-dev) because the IR with "-Xclang -disable-llvm-optzns" shows the difference.<br class=""><br class="">But independently of that, there's a missing IR canonicalization - instcombine doesn't currently do anything with either version.<br class=""><br class=""></div>And the version where we trunc later survives through the backend and produces worse code even for x86 with AVX2:<br class="">before:<br class=""> vmovd %edi, %xmm1<br class=""> vpmovzxwq %xmm1, %xmm1 <br class=""> vpsraw %xmm1, %xmm0, %xmm0<br class=""> retq<br class=""><br class="">after:<br class=""> vmovd %edi, %xmm1<br class=""> vpbroadcastd %xmm1, %ymm1<br class=""> vmovdqa LCPI1_0(%rip), %ymm2 <br class=""> vpshufb %ymm2, %ymm1, %ymm1<br class=""> vpermq $232, %ymm1, %ymm1 <br class=""> vpmovzxwd %xmm1, %ymm1 <br class=""> vpmovsxwd %xmm0, %ymm0<br class=""> vpsravd %ymm1, %ymm0, %ymm0<br class=""> vpshufb %ymm2, %ymm0, %ymm0<br class=""> vpermq $232, %ymm0, %ymm0 <br class=""> vzeroupper<br class=""><br class=""><br class=""></div>So this example may have won the bug lottery by exposing all of front-, middle-, back-end bugs. :)<br class=""><div class=""><br class=""><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote"><div class=""><div class="m_-8900007202819893423m_6613147576831423662h5">On Fri, Feb 17, 2017 at 9:38 AM, Saurabh Verma via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div class="m_-8900007202819893423m_6613147576831423662h5"><div dir="ltr" class="">Correction in the C snippet:<div class=""><div class=""><br class=""></div><div class=""><div class="">typedef signed short v8i16_t __attribute__((ext_vector_type<wbr class="">(8)));</div><div class=""><br class=""></div><div class=""><div class=""><div class="">v8i16_t foo (v8i16_t a, int n)</div><div class="">{</div><div class=""> return a >> n;<br class=""></div><div class="">}<br class=""></div></div></div></div><div class=""><br class=""></div><div class="gmail_extra">Best regards</div><span class="m_-8900007202819893423m_6613147576831423662m_-2695995442535747064m_-1598343854329839733HOEnZb"><font color="#888888" class=""><div class="gmail_extra">Saurabh</div></font></span><div class=""><div class="m_-8900007202819893423m_6613147576831423662m_-2695995442535747064m_-1598343854329839733h5"><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On 17 February 2017 at 16:21, Saurabh Verma <span dir="ltr" class=""><<a href="mailto:saurabh.verma@movidius.com" target="_blank" class="">saurabh.verma@movidius.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">Hello,<div class=""><br class=""></div><div class="">We are investigating a difference in code generation for vector splat instructions between llvm-3.9 and llvm-4.0, which could lead to a performance regression for our target. Here is the C snippet</div><div class=""><br class=""></div><div class="">typedef signed v8i16_t __attribute__((ext_vector_type<wbr class="">(8)))<br class=""></div><div class=""><div class=""><br class=""></div><div class="">v8i16_t foo (v8i16 a, int n)</div><div class="">{</div><div class=""> return result = a >> n;<br class=""></div><div class="">}<br class=""></div></div><div class=""><br class=""></div><div class="">With llvm-3.9, the generated sequence does a trunc followed by splat, but with llvm-4.0 it is reversed to a splat to a bigger vector followed by a v8i32->v8i16 trunc. Is this by design? The earlier code sequence is definitely better for our target, but are there known scenarios where the new sequence would lead to better code?</div><div class=""><br class=""></div><div class="">Here are the instruction sequences generated in the two cases:</div><div class=""><br class=""></div><div class="">With llvm 3.9:</div><div class=""><br class=""></div><div class=""><div class="">define <8 x i16> @foo(<8 x i16>, i32) #0 {</div><div class=""> %3 = trunc i32 %1 to i16</div><div class=""> %4 = insertelement <8 x i16> undef, i16 %3, i32 0</div><div class=""> %5 = shufflevector <8 x i16> %4, <8 x i16> undef, <8 x i32> zeroinitializer</div><div class=""> %6 = ashr <8 x i16> %0, %5</div><div class=""> ret <8 x i16> %6</div><div class="">}</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">With llvm 4.0:</div><div class=""><br class=""></div><div class=""><div class="">define <8 x i16> @foo(<8 x i16>, i32) #0 {</div><div class=""> %3 = insertelement <8 x i32> undef, i32 %1, i32 0</div><div class=""> %4 = shufflevector <8 x i32> %3, <8 x i32> undef, <8 x i32> zeroinitializer</div><div class=""> %5 = trunc <8 x i32> %4 to <8 x i16></div><div class=""> %6 = ashr <8 x i16> %0, %5</div><div class=""> ret <8 x i16> %6</div><div class="">}</div></div><div class=""><br class=""></div><div class="">Best regards</div><span class="m_-8900007202819893423m_6613147576831423662m_-2695995442535747064m_-1598343854329839733m_6843872365919815996gmail-HOEnZb"><font color="#888888" class=""><div class="">Saurabh Verma</div></font></span></div>
</blockquote></div><br class=""></div></div></div></div></div>
<br class=""></div></div>______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
<br class=""></blockquote></div><br class=""></div></div>
</blockquote></div><br class=""></div>
</div></div></blockquote></div><br class=""></div>
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""></body></html>