<div class="gmail_quote">On Mon, Feb 23, 2009 at 4:03 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 style=""><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></div></blockquote><div><br>Fine. For vector shuffles. But again, what about vector constants, e.g., v4i32 <0, 1, 2, 3, 4>? BuildVectorSDNode is still a reasonable subclass to have for encapsulating constant vectors (should be renamed, but hey, it's what it's called today.)<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><div></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>
</div></div></blockquote><div><br>You're talking about moving the functionality to a class where it makes no sense to look for it. That's one issue where I disagree and would argue for good O-O software design. At least my patch puts the functionality in a place where it's reasonable to expect it reside.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><div></div><div class="Ih2E3d"><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><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></div></blockquote><div><br>What about this case where the arguments are entirely variable and you have no knowledge of their contents:<br><br><font face="courier new,monospace">define <4 x i32> @v4i32_shuffle(<4 x i32> %a, <4 x i32> %b) nounwind readnone {<br>
entry:<br>        %tmp1 = shufflevector <4 x i32> %a, <4 x i32> %b, <4 x i32> < i32 1, i32 2, i32 3, i32 0 ><br>        ret <4 x i32> %tmp1<br>}</font><br></div></div><br>It's perfectly legit LLVM code and it's a case where the two input operands are variables, not constants. Only the mask is a constant.<br>
<br><br>-scooter<br>