search for: shufflevectorsdnod

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

...; > 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 l...

...6 PM, Chris Lattner <clattner at apple.com> > wrote: > > 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, >> e.g., v4i32 <0, 1, 2, 3, 4>? BuildVectorSDNode is still a >> reasonable subclass to have for...

...gt; > 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 &g...

...23, 2009 at 8:26 PM, Chris Lattner <clattner at apple.com> wrote: > > 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, e.g., > v4i32 <0, 1, 2, 3, 4>? BuildVectorSDNode is still a reasonable subclass to > have for encapsulating constant...

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, > e.g., v4i32 <0, 1, 2, 3, 4>? BuildVectorSDNode is still a reasonable > subclass to have for encapsulating constant...

...) I really appreciate your thoroughness and the fact that the patch apparently didn't break anything. 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. The important part of #3 is that we really want an array of ints (using -1 for undef) for th...

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

...(v4i64 (vperm2f128:$src3 VR256:$src1, (v4i64 (memop addr:$src2)))))], and verpm2f128 is defined as: def vperm2f128 : PatFrag<(ops node:$src1, node:$src2), (vector_shuffle node:$src1, node:$src2), [{ return X86::isVPERM2F128Mask(cast<ShuffleVectorSDNode>(N)); }], SHUFFLE_get_vperm2f128_imm>; I don't understand completely how the new system all works. Take a simple SHUFPS match: def SHUFPSrri : PSIi8<0xC6, MRMSrcReg, (outs VR128:$dst), (ins VR128:$src1, VR128:$src2, i8imm:$sr...

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, e.g., v4i32 <0, 1, 2, 3, 4>? BuildVectorSDNode is still a reasonable subclass to have for encapsulating constant vectors (should be renamed,...

> 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". Th...

...bigger picture enough yet. > >> but IMHO the implementation of x86 shuffle matching is a lot more >> clear now then they used to be in the past. > > There's certainly been improvement on the TableGen side of things.  I > really liked the unpck*, shufp, etc. nodes and the ShuffleVectorSDNode. > That's a huge help.  It's too bad we're getting rid of them.  But > legalization still looks about the same to me. The idea is to use tablegen again once we have a clean implementation. It would be good to have all tables and per-processor logic in a tablegen file, but I thin...

...r 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 free.fr> > wrote: > > 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 "...

...really thought about the bigger picture enough yet. > but IMHO the implementation of x86 shuffle matching is a lot more > clear now then they used to be in the past. There's certainly been improvement on the TableGen side of things. I really liked the unpck*, shufp, etc. nodes and the ShuffleVectorSDNode. That's a huge help. It's too bad we're getting rid of them. But legalization still looks about the same to me. Thanks for the explanation. -Dave

...In X86InstrFragmentsSIMD.td: def SHUFFLE_get_shuf_imm : SDNodeXForm<vector_shuffle, [{ return getI8Imm(X86::getShuffleSHUFImmediate(N)); }]>; def shufp : PatFrag<(ops node:$lhs, node:$rhs), (vector_shuffle node:$lhs, node:$rhs), [{ return X86::isSHUFPMask(cast<ShuffleVectorSDNode>(N)); }], SHUFFLE_get_shuf_imm>; Ok, so far this is exactly the same as today. What we eliminate is this: void X86TargetLowering::LowerVECTOR_SHUFFLE(SDValue Op, SelectionDAG &DAG) { ... isShuffleMaskLegal(...) } bool X86TargetLowering::isShuffleMaskLegal(const SmallVectorImpl&lt...

...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 free.fr> >> wrote: >> > 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) f...

> In the experience I just had, it is quite error-prone to have multiple > tblgen patterns to match these things.  The way things were before, > there was a clean separation between checking/enforcing node legality > and doing the final code selection, with isel being automatic through > tblgen.  That was nice.  The current setup mixes the two and seems to > result in more code

...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 free.fr> wrote: > > 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 "...

...th 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 free.fr> wrote: >> >>> > 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 fo...

...tor 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 free.fr> wrote: > >> > 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 shuf...