llvm dev - Feb 2009 - [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/

On Feb 23, 2009, at 1:46 PM, Chris Lattner wrote:
> In my opinion, the proper direction for shuffles is:
>
> 1. Back out your patch.
> 2. Move the functionality of "is splat" etc to method somewhere,
e.g.
> on SDNode.
> 3. Introduce a new ShuffleVectorSDNode that only has two SDValue
> operands (the two input vectors), but that also contains an array of
> ints in the node (not as operands).
> 4. Move the helper functions from #2 back into ShuffleVectorSDNode.
I'm working on #2 and #3 right now, and hope to land something in the  
next couple days.

Nate

On Mon, Feb 23, 2009 at 2:19 PM, Nate Begeman <natebegeman at me.com>
wrote:
>
> On Feb 23, 2009, at 1:46 PM, Chris Lattner wrote:
>
>  In my opinion, the proper direction for shuffles is:
>>
>> 1. Back out your patch.
>> 2. Move the functionality of "is splat" etc to method
somewhere, e.g.
>> on SDNode.
>> 3. Introduce a new ShuffleVectorSDNode that only has two SDValue
>> operands (the two input vectors), but that also contains an array of
>> ints in the node (not as operands).
>> 4. Move the helper functions from #2 back into ShuffleVectorSDNode.
>>
>
> I'm working on #2 and #3 right now, and hope to land something in the
next
> couple days.

Details, since this has implications for vector machine backends?

I'm just not groking how moving isSplat to SDNode eliminates BUILD_VECTOR or
deals with constant vector formation. 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.


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

On Feb 23, 2009, at 2:49 PM, Scott Michel wrote:
> On Mon, Feb 23, 2009 at 2:19 PM, Nate Begeman <natebegeman at me.com>
> wrote:
>
> On Feb 23, 2009, at 1:46 PM, Chris Lattner wrote:
>
> In my opinion, the proper direction for shuffles is:
>
> 1. Back out your patch.
> 2. Move the functionality of "is splat" etc to method somewhere,
e.g.
> on SDNode.
> 3. Introduce a new ShuffleVectorSDNode that only has two SDValue
> operands (the two input vectors), but that also contains an array of
> ints in the node (not as operands).
> 4. Move the helper functions from #2 back into ShuffleVectorSDNode.
>
> I'm working on #2 and #3 right now, and hope to land something in  
> the next couple days.
>
> Details, since this has implications for vector machine backends?
It's basically as  Chris said; there will be a ShuffleVectorSDNode,  
and appropriate helper functions, node profile, and DAGCombiner support.
> I'm just not groking how moving isSplat to SDNode eliminates  
> BUILD_VECTOR or deals with constant vector formation.
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.
> 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.

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