search for: buildvectorsdnod

...d would have to check is if this > SDNode is a BUILD_VECTOR node, right? Right. It's really not much different than what you have now, just moving the point where you check. In your code right now, when you want to call your isConstantSplat method, you first dyn_cast the node to a BuildVectorSDNode. Just move 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...

...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 target-specific SDNode >> polymorphism is an issue that has to be addressed, in light of the vector >> swizzling support conversation thre...

...9;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 variabl...

...> 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're talking about two very very very different things: shuffle_vector "masks" and constant vectors. Constant vectors have...

...tebegeman 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. &gt...

...; >> >> 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're talking about two very very very different things: shuffle_vector > "masks" and constant vectors. > Yup....

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

Duncan: I'm still stymied how this whole thread ended up about shuffle vector nodes, when the original problem was my build vector patch. I'm still working on backing the build vector patch out (it isn't clean with all of the intervening commits and I have pressing management tasks which command my attention.) -scooter On Tue, Feb 24, 2009 at 12:28 AM, Duncan Sands <baldrick at

> 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). ... > The important part of #3 is that we really want an array of ints > (using -1 for undef) for the shuffle mask, not "operands". This > eliminates the nastiness we have now were we

...; 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're talking about two very very very different things: > shuffle_vector "masks" and constant vectors. &...

Scott, In case you missed it, I reimplemented your BuildVectorSDNode::isConstantSplat method following the suggestions from Chris. The revised version passes "make check" for llvm. Assuming that it also passes Evan's tests, I think it should also do what you need for CellSPU. On Feb 25, 2009, at 12:16 PM, Scott Michel wrote: > Evan: >...

...gt; On Feb 22, 2009, at 3:36 PM, Scott Michel wrote: >> >> Author: pingbak >>> Date: Sun Feb 22 17:36:09 2009 >>> New Revision: 65296 >>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=65296&view=rev >>> Log: >>> Introduce the BuildVectorSDNode class that encapsulates the >>> ISD::BUILD_VECTOR >>> instruction. The class also consolidates the code for detecting >>> constant >>> splats that's shared across PowerPC and the CellSPU backends (and >>> might be >>> useful for other backe...

On Feb 23, 2009, at 1:20 PM, Scott Michel wrote: > Chris: > > I did float this by the dev list first a couple of weeks ago, didn't > receive any comments. Ok, I didn't see it, sorry about that. > 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

Things are still broken. Unfortunately llvm test suite does not contain enough vector code to fully test this. Can you revert the patch first? Evan On Feb 24, 2009, at 7:14 PM, Scott Michel wrote: > Evan: > > I did not encounter this back trace before I committed the newest > BuildVectorSDNode patch, which removed all class instance members > and passes results back via reference parameters. > > > -scooter > > On Tue, Feb 24, 2009 at 11:39 AM, Evan Cheng <evan.cheng at apple.com> > wrote: > I believe this patch has broken a PPC app that I am tracking. H...

...ll broken. Unfortunately llvm test suite does not contain > enough vector code to fully test this. Can you revert the patch first? > Evan > > On Feb 24, 2009, at 7:14 PM, Scott Michel wrote: > > Evan: > > I did not encounter this back trace before I committed the newest > BuildVectorSDNode patch, which removed all class instance members and passes > results back via reference parameters. > > > -scooter > > On Tue, Feb 24, 2009 at 11:39 AM, Evan Cheng <evan.cheng at apple.com> wrote: > >> I believe this patch has broken a PPC app that I am tracking. H...

Evan: I did not encounter this back trace before I committed the newest BuildVectorSDNode patch, which removed all class instance members and passes results back via reference parameters. -scooter On Tue, Feb 24, 2009 at 11:39 AM, Evan Cheng <evan.cheng at apple.com> wrote: > I believe this patch has broken a PPC app that I am tracking. Here is a > reduced test case. Re...

I believe this patch has broken a PPC app that I am tracking. Here is a reduced test case. Reproduce with llc -mattr=+Altivec -mcpu=g5. The backtrace looks like this: #0 0x9333ae42 in __kill () #1 0x9333ae34 in kill$UNIX2003 () #2 0x933ad23a in raise () #3 0x933b9679 in abort () #4 0x933ae3db in __assert_rtn () #5 0x0008bd8f in llvm::MVT::getVectorElementType (this=0xbfffdda4) at

...getting the following error. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> llc: /lib/Target/X86/X86ISelLowering.cpp:6801: >>>>>>>>>>>>>>> llvm::SDValue LowerVectorBroadcast(llvm::BuildVectorSDNode >>>>>>>>>>>>>>> *, const llvm::X86Subtarget &, llvm::SelectionDAG &): Assertion >>>>>>>>>>>>>>> `(VT.is128BitVector() || VT.is256BitVector() || VT.is512BitVector()) && >>>>>>...

...ror. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> llc: /lib/Target/X86/X86ISelLowering.cpp:6801: >>>>>>>>>>>>>>>>> llvm::SDValue LowerVectorBroadcast(llvm::BuildVectorSDNode >>>>>>>>>>>>>>>>> *, const llvm::X86Subtarget &, llvm::SelectionDAG &): Assertion >>>>>>>>>>>>>>>>> `(VT.is128BitVector() || VT.is256BitVector() || VT.is512BitVector()) && >>...