[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/

[Scott Michel]

On Mon, Feb 23, 2009 at 4:03 PM, Nate Begeman <natebegeman at me.com> wrote:

>
> It's basically as  Chris said; there will be a ShuffleVectorSDNode, and
> appropriate helper functions, node profile, and DAGCombiner support.
>

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.)

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.
>

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.

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.
>
>
> 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.
>

What about this case where the arguments are entirely variable and you have
no knowledge of their contents:

define <4 x i32> @v4i32_shuffle(<4 x i32> %a, <4 x i32> %b) nounwind
readnone {
entry:
        %tmp1 = shufflevector <4 x i32> %a, <4 x i32> %b, <4 x i32> < i32 1,
i32 2, i32 3, i32 0 >
        ret <4 x i32> %tmp1
}

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.


-scooter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090223/c06751ae/attachment.html>