<div dir="ltr">And I've just enhanced the AVX side more. It now leverages the variable VPERMILPS formation that I think LLVM has historically completely failed to utilize when lowering AVX code. =]<div><br></div><div>AVX2 is still in-flight.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 19, 2014 at 10:15 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">After some adding some serious ninja-ry to the new shuffle lowering...</div><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Fri, Sep 19, 2014 at 11:53 AM, Quentin Colombet <span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>2. none_useless_shuflle none</div><div>Instead of using a single move to materialize a zero extended constant into a vector register, we explicitly zeroed a vector register and use a shuffle.</div></blockquote></div><br></span>... this test case is fixed, as is your 'pxor.ll' test case from earlier, and the 'movss' test cases from Andrea earlier in the thread (I suspect). Turns out that there is a trick that we can use in the existing tables to get most of the memory-operand-movss optimizations.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think this is all of the non-avx-specific issues raised thus far.... One of the issues isn't avx specific but can only be solved with avx. Anyways, I'll look into some of the AVX issues next.</div></div>
</blockquote></div><br></div>