<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 23, 2009, at 2:49 PM, Scott Michel wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Mon, Feb 23, 2009 at 2:19 PM, Nate Begeman <span dir="ltr"><<a href="mailto:natebegeman@me.com">natebegeman@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
On Feb 23, 2009, at 1:46 PM, Chris Lattner wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In my opinion, the proper direction for shuffles is:<br>
<br>
1. Back out your patch.<br>
2. Move the functionality of "is splat" etc to method somewhere, e.g.<br>
on SDNode.<br>
3. Introduce a new ShuffleVectorSDNode that only has two SDValue<br>
operands (the two input vectors), but that also contains an array of<br>
ints in the node (not as operands).<br>
4. Move the helper functions from #2 back into ShuffleVectorSDNode.<br>
</blockquote>
<br></div>
I'm working on #2 and #3 right now, and hope to land something in the next couple days.<font color="#888888"></font></blockquote><div><br>Details, since this has implications for vector machine backends?<br></div></div></blockquote><div><br></div><div>It's basically as Chris said; there will be a ShuffleVectorSDNode, and appropriate helper functions, node profile, and DAGCombiner support.</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><div>I'm just not groking how moving isSplat to SDNode eliminates BUILD_VECTOR or deals with constant vector formation. </div></div></blockquote><div><br></div><div>You can have a static method on SDNode that took an SDNode, checked if it was a build vector, and calculated whatever splat information you wanted. There's no need for BuildVectorSDNode for this particular functionality.</div><br><blockquote type="cite"><div class="gmail_quote"><div>I like the idea of a ShuffleVectorSDNode (moves things in the direction of a bijective ISD to SDNode mapping), but eliminating BuildVectorSDNode in its entirety doesn't deal with constant and variable vectors.<br></div></div></blockquote><div><br></div><div>LLVM has no variable shuffle instruction, so there's no variable vectors to deal with; moving the constants into the shuffle sdnode does address constant shuffles (which are all of them). Variable shuffles would need to be represented as target nodes at present, and my work will not change that.</div><div><br></div><div>Nate</div></div></body></html>