search for: isconstantsplat

Is anyone going to develop acute heartburn if I move these two functions as TargetLowering methods? It seems that they're used frequently enough across multiple backends and provide common functionality. I could be convinced that TargetLowering is the wrong place to put these functions as methods and that they're better off in a separate BUILD_VECTOR SDValue class. Comments? -scooter

...ott Michel wrote: > And the first thing the helper method 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 function...

On Mon, Feb 23, 2009 at 1:46 PM, Chris Lattner <clattner at apple.com> wrote: > > 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 happens. :-) > a) Convenience for the

...nstant, you don't want to end up with shufflevectors of > loads of the mask from the constant pool. > Never disagreed with that point. But recall what you had previous written and quoted above. Hence my confusion when you wrote step #4 -- that's an even less logical place to look for isConstantSplat functionality and is really misplaced. 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. >> > &...

On Feb 23, 2009, at 6:13 PM, Scott Michel wrote: > 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, >

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: > > I work on rev...

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

Evan: I work on reverting it, although, when I tried yesterday, it wasn't particularly clean (lots of rejected patches, presumably due to intervening commits.) Are you still getting the backtrace or is this just a case of incorrectly generated code? -scooter On Wed, Feb 25, 2009 at 10:09 AM, Evan Cheng <echeng at apple.com> wrote: > Things are still broken. Unfortunately llvm

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