search for: shuffle_vector

I'm not quite clear what BUILD_VECTOR and SHUFFLE_VECTOR instructions do. I understand that they somehow build a vector and shuffle a vector, but how exactly it translates into a given target, that I can not figure out. I also tried reading code for other targets but I really lack experience. Would anyone be able to give a clear explanation, maybe even a...

Is there an established way of disabling a DAG combine on a per target basis, where it appears to be detrimental to the generated code? Writing if (!mytarget) in DAGCombiner.cpp works but tends to be erased by git merge and generally doesn't look ideal. Writing the inverse transform in target specific code doesn't work in this instance and in general creates an infinite loop. Guidance

...t 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 to be legal for a target. This has implications for legalization and many other things. BUILD_VECTOR is fine for them. Shuffle masks do not and should not be legalized as a build_vector. If you have a machine that has shuffles b...

...> 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. That's why I was absolutely mystified when you proposed the > following: > > 2. Move the functionality of "is splat" etc to method somewhere, > e.g. on SDNode. > 3. Introduce a new ShuffleVectorSDNode that only...

...ot be complete yet. >> I don't have experience of the new vector instructions in LLVM, and >> perhaps >> that's why it makes me feel it's complicated to fold the swizzle and >> writemask. We have really good support for swizzling operations already with the shuffle_vector instruction. I'm not sure about writemask. > > Um, I was thinking that we should eventually create intrinsic > functions > for some of the commands, like LIT, that might not be > single-instruction, but that can be lowered eventually, and for > commands > like LG2, th...

...or 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. That's why I was absolutely mystified when you proposed the following: 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 (t...

Alex wrote: > Hello. > > Sorry I am not sure this question should go to llvm or mesa3d-dev mailing > list, so I post it to both. > > I am writing a llvm backend for a modern graphics processor which has a ISA > very similar to that of Direct 3D. > > I am reading the code in Gallium-3D driver in a mesa3d branch, which > converts the shader programs (TGSI tokens) to

...uffles. I suspect "natural" shuffles will fare better. On <16 x *> -> <8 x *> shuffles, it rarely performs any optimization. Probably only 0.03 instructions shorter on average. The problem is that not many random shuffles actually have known good encodings, so the existing SHUFFLE_VECTOR handling refuses to deal with them usually. Again I'd expect natural shuffles to do better. The code is disabled on shorter vectors because my tests suggested the transformations weren't improving matters. (The extract_subvector code still applies -- it will always be better). I would wel...

Hi, We are now about halfway between the 3.4 and 3.5 releases, and I would like to start preparing for a 3.4.1 release. Here is my proposed release schedule: Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. April 9 - April 18: Testing Phase April 18: 3.4.1 Release How you can help: - If you have any bug fixes you think should be included to 3.4.1, send me an

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

Hello. Sorry I am not sure this question should go to llvm or mesa3d-dev mailing list, so I post it to both. I am writing a llvm backend for a modern graphics processor which has a ISA very similar to that of Direct 3D. I am reading the code in Gallium-3D driver in a mesa3d branch, which converts the shader programs (TGSI tokens) to LLVM IR. For the shader instruction also found in LLVM IR,

...This will > eliminate a lot of confusing and redundant code in X86ISelLowering. I don't really see where you're going with this. I agree that there is confusing and fragile code for shuffle lowering, but this is what Bruno is working on fixing. To me, the problem is that legalize of SHUFFLE_VECTOR eliminates shuffles that are not directly matchable into a single machine instruction, but preserves ones that do match. This means that there is duplicated code in both legalize and isel that has to know that a shuffle is an "unpacklps" or whatever. Other parts of the code that generat...

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

...> I don't have experience of the new vector instructions in LLVM, and > >> perhaps > >> that's why it makes me feel it's complicated to fold the swizzle and > >> writemask. > > We have really good support for swizzling operations already with the > shuffle_vector instruction. I'm not sure about writemask. With SOA they're rarely used (essentially never unless we "kill" a pixel") [4 x <4 x float> ] {{xxxx, yyyy, zzzz, wwww}, {xxxx, yyyy, zzzz, www}...} so with SOA both shuffles and writemask come down to a simple selection of...

Chris Lattner <clattner at apple.com> writes: >> We would still keep the existing pre-table-driven-isel passes so we'd >> still have a chance to do some cleanup before the main table-driven >> isel. >> >> Obviously a lot of details have to be worked out. > > I'm not seeing how this is useful for shuffles. Since tblgen doesn't > generate

...isrupted. In SelectionDAG, shuffles aren't really unified the same way they are in IR. I think we map onto existing operations where they make sense (CONCAT_VECTORS and EXTRACT_SUBVECTOR). For scalable zip/unzip, I haven't really thought deeply about it; it probably makes sense to change SHUFFLE_VECTOR's shuffle mask to use ShuffleMask like IR, but that probably doesn't have a big impact either way. -Eli

Currently, for scalable vectors, only splat shuffles are allowed; we're considering allowing more different kinds of shuffles. The issue is, essentially, that a shuffle mask is a simple list of integers, and that isn't enough to express a scalable operation. For example, concatenating two fixed-length vectors currently looks like this: shufflevector <2 x i32> %v1, <2 x i32>