<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 21, 2014 at 2:18 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.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"><div class="gmail_quote"><div class="">On Mon, Jul 7, 2014 at 10:41 AM, Evan Cheng <span dir="ltr"><<a href="mailto:evan.cheng@apple.com" target="_blank">evan.cheng@apple.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Have you considered using / extending perfect shuffle to replace some of the logic?<br></blockquote><div><br></div></div>
<div>
Sorry for not replying promptly here.</div><div><br></div><div>I did think about perfect shuffles, but I don't think they're going to help much. Fundamentally, perfect shuffle tables don't scale well enough to be usable. For just 8 lanes, we're talking about nearly 7 billion entries. Even assuming a *bunch* of folding through symmetry and other tricks, we're not going to get it to a reasonable.</div>
</div></div></div></blockquote><div><br></div><div>This may be something to punt over to the "academia" side of the fence (I think Chris may have already done this in one of his talks?). I would be pretty surprised if there wasn't some fairly straightforward formal model for the problem with an efficient solution. It's basically an optimization problem on compositions of permutations, and permutations have a fairly nice structure which seems like it could be easily exploited.<br>
</div><div> </div><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"><div class="gmail_quote"><div> So we can only use perfect shuffle tables for 4 lanes and smaller. But for 4 lanes and smaller x86 has essentially perfect shuffle *instructions* and all the tricky parts are balancing blend vs. shuffle operations and the potential for domain crossing penalties.</div>
</div></div></div></blockquote><div><br></div><div>Can you clarify what you mean by "perfect shuffle *instructions*"? I thought the whole point of PerfectShuffle is precisely to choose "cheaper" less-general shuffles when possible and better than using a full permute instruction.<br>
<br></div><div>-- Sean Silva<br></div><div> </div><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"><div class="gmail_quote"><div>
 Those seem reasonably handled by basic code logic and DAG combines rather than table-driven approaches.</div>
<div><br></div><div>The other thing that I realized that led me down this path is that there is a very fundamental logic to the shuffle instructions on the architecture, and the best way to lower shuffle operations is to actually follow that logic itself. That leads to the decomposition structure of the code here.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>-Chandler</div></font></span></div></div></div>
<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>
<br></blockquote></div><br></div></div>