<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 6, 2013 at 11:44 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On May 6, 2013, at 4:32 PM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>

> There is a nice lattice structure on the set of shuffle compositions (roughly, "instruction sequences") imposed by the prefix relation. Also, the above cost function should be monotonic on this lattice since shuffle costs are strictly positive. At the very least, the lattice structure together with a cost function monotonic on the lattice should allow some amount of pruning over a brute force search. A cost function like this also would be amenable to A* search (although I have no clue what heuristic function would be appropriate).<br>

><br>
> That's all I was able to come up with today (while waiting at the DMV...). I still need to think some more about how to impose more structure (than just "black box" functions) on the set of all possible shuffles (and hence on the shuffle classes). Primarily, this structure would enable reasoning about "dead ends" when composing shuffles. For example with AVX, if the desired shuffle does not move elements across 128-bit lanes, then all PSHUFB shuffles that cross lanes are "dead ends" in the search space (this applies more to the problem of computing perfect shuffles online, rather than building tables).<br>

<br>
</div>This is an interesting way to look at it.  Here is a related, but different way, with some backstory:<br>
<br>
The perfect shuffle code does a really good job on PPC, for 4-element vectors.  This width is really important for GLSL, OpenCL and related graphics technologies (so it is an important special case) but doesn't handle PPC's other cases, including v16i8.  As others have noted, "perfect shuffle" doesn't work in the general case because of huge table size... but what if we changed the tables?<br>

<br>
At least on PPC, perfect shuffle is only used when a shuffle has a cost of 3 or less.  If you look at the table that gets indexed into, we have:<br></blockquote><div><br></div><div style>It looks like the check in PPCISelLowering.cpp is actually < 3:</div>
<div style><div>    if (Cost < 3)</div><div>      return GeneratePerfectShuffle(PFEntry, V1, V2, DAG, dl);</div><div><br></div><div style>which reduces the used part of the table to more along the lines of 26% (and hence 74% of the table is unused).</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
// 31 entries have cost 0<br>
// 292 entries have cost 1<br>
// 1384 entries have cost 2<br>
// 3061 entries have cost 3<br>
// 1733 entries have cost 4<br>
// 60 entries have cost 5<br>
<br>
... which means that ~73% of the table entries are actually used, which makes this a good encoding for PPC.  If you bump out the table to a vector width of 8 or wider though, I have not proven this, but I suspect that the vast majority of the table would be dead: it may be possible to generate every crazy shuffle, but the generated code would never be used, so it isn't worth storing in the table.<br>
</blockquote><div><br></div><div><br></div><div style>-- Sean Silva </div></div></div></div>