search for: shufflesdnod

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