Displaying 4 results from an estimated 4 matches for "shufflesdnod".
Did you mean:
shufflesdnode
2009 Feb 23
2
[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/
...ode
is a BUILD_VECTOR node, right?
b) Where else would one encapsulate a constant splat predicate?
>> SelectionDAG and SDNode are not good classes for constant splat detection,
>> since it's functionality specific to building vectors.
>>
>
> Eventually we need to add a ShuffleSDNode class for other reasons. Parking
> it on SelectionDAG or SDNode is not a good place to put it.
Ok, so that's a subclass of BuildVectorSDNode or the ShuffleSDNode class is
passed one or more BuildVectorSDNode operands (vide infra.)
> c) Future work. At some point (or another), having...
2009 Feb 23
0
[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/
...helper methods would have the same
functionality.
> b) Where else would one encapsulate a constant splat predicate?
> SelectionDAG and SDNode are not good classes for constant splat
> detection, since it's functionality specific to building vectors.
Eventually we need to add a ShuffleSDNode class for other reasons.
Parking it on SelectionDAG or SDNode is not a good place to put it.
>
> c) Future work. At some point (or another), having target-specific
> SDNode polymorphism is an issue that has to be addressed, in light
> of the vector swizzling support conversatio...
2009 Feb 23
0
[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/
...the check inside isConstantSplat.
>
>
> b) Where else would one encapsulate a constant splat predicate?
> SelectionDAG and SDNode are not good classes for constant splat
> detection, since it's functionality specific to building vectors.
>
> Eventually we need to add a ShuffleSDNode class for other reasons.
> Parking it on SelectionDAG or SDNode is not a good place to put it.
>
> Ok, so that's a subclass of BuildVectorSDNode or the ShuffleSDNode
> class is passed one or more BuildVectorSDNode operands (vide infra.)
There are a couple of different issues...
2009 Feb 23
4
[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/
Chris:
I did float this by the dev list first a couple of weeks ago, didn't receive
any comments. It's not entirely gratuitous; the rationale for adding a new
node class is threefold:
a) Convenience for the backends. Since it benefits multiple backends (PPC
and CellSPU), it's a logical addition. I reckon the GPU efforts would also
benefit.
b) Where else would one encapsulate a