search for: unpck

...In the way it was done before, every shuffle that we tried to match > had to be checked twice (masks used to be checked during legalization > and during isel by the tblgen patterns), Right. > this is done only once now (during legalization). Maybe. We still have the old operators like unpck and shup, so couldn't those still trigger? Shouldn't we remove them if we're using this TargetNode method? Is it very expensive to check masks, in the grand scheme of things? > Although we still match the node itself through tblgen patterns, the > tablegen patterns are a lot mo...

> 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

> Maybe.  We still have the old operators like unpck and shup, so couldn't > those still trigger?  Shouldn't we remove them if we're using this > TargetNode method? > > Is it very expensive to check masks, in the grand scheme of things? Probably not, in the old scheme the masks could be checked more than once during legalizat...

...... > For X86, legalize will convert each insertelement to become a vector > shuffle. We are very careful in combining vector shuffles because we don't > want to produce a vector shuffle whose mask is illegal or hard to code gen > so we end up in this code to generate a sequence of unpcks and movhlps for > this. With the new form, Legalize will divide the 8xf32 vector into two > 4xf32 and since the two sides are the same, it will generate quad word moves > to copy the values. I think this specific issue can be fixed without extending the IL-level syntax; DAGCombiner coul...

...i32 1 ... For X86, legalize will convert each insertelement to become a vector shuffle. We are very careful in combining vector shuffles because we don't want to produce a vector shuffle whose mask is illegal or hard to code gen so we end up in this code to generate a sequence of unpcks and movhlps for this. With the new form, Legalize will divide the 8xf32 vector into two 4xf32 and since the two sides are the same, it will generate quad word moves to copy the values. There are other cases when a user write vector code, the generation of extract element and insert eleme...

...V2.isUndef()) { return DAG.getNode(X86ISD::PSHUFD_P64, DL, MVT::v64i32, V1, getV16X86ShuffleImm64ForMask(/*Repeated*/Mask, DL, DAG)); } // Use dedicated unpack instructions for masks that match their pattern. if (SDValue V = lowerVectorShuffleWithUNPCK(DL, MVT::v64i32, Mask, V1, V2, DAG)) return V; } // Try to use shift instructions. if (SDValue Shift = lowerVectorShuffleAsShift(DL, MVT::v64i32, V1, V2, Mask, Zeroable, Subtarget, DAG)) return Shift; // Try to use VALIGN. if (...

...one more integrating of AVX work upstream and more tuning here, > I've run across several things which are clunky in the current isel > design. A couple examples I can remember offhand: > > 1. We have special target-specific operators for certain shuffles in X86, > such as X86unpckl. I don't completely understand why but Bruno > indicated it was to address inefficiecies. One of those is the need > to check masks multiple times (once at legalize and again at isel). It also eliminates a lot of fragility. Before doing this, X86 legalize would have to be very ca...

Bruno Cardoso Lopes <bruno.cardoso at gmail.com> writes: >> 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. Ah, good. Having a clear...

All, As I've done more integrating of AVX work upstream and more tuning here, I've run across several things which are clunky in the current isel design. A couple examples I can remember offhand: 1. We have special target-specific operators for certain shuffles in X86, such as X86unpckl. I don't completely understand why but Bruno indicated it was to address inefficiecies. One of those is the need to check masks multiple times (once at legalize and again at isel). 2. Sometimes DAGs are legal in some contexts but not others and it is a pain to deal with. A good ex...

Chris Lattner <clattner at apple.com> writes: >> 1. We have special target-specific operators for certain shuffles in X86, >> such as X86unpckl. > It also eliminates a lot of fragility. Before doing this, X86 > legalize would have to be very careful to specifically form shuffles > that it knew isel would turn into (e.g.) unpck operations. Now > instead of forming specific carefully constructed shuffle masks (not > making...

On Sep 21, 2010, at 5:30 PMPDT, Bill Wendling wrote: > LLVM isn't going to stop generating MMX instructions all together. We can't do that. :-) If the user specifically wants MMX (by, say, using the builtins), we have to support that still. The plan to cease generating MMX for generic vectors is a work-in-progress right now. It's not in 2.8. > > -bw Right, early on there

On Tue, Sep 9, 2014 at 11:39 PM, Chandler Carruth <chandlerc at google.com> wrote: > Awesome, thanks for all the information! > > See below: > > On Tue, Sep 9, 2014 at 6:13 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> > wrote: >> >> You have already mentioned how the new shuffle lowering is missing >> some features; for example, you explicitly

On Mar 17, 2011, at 9:32 AM, David A. Greene wrote: > Chris Lattner <clattner at apple.com> writes: >>> 1. We have special target-specific operators for certain shuffles in X86, >>> such as X86unpckl. > >> It also eliminates a lot of fragility. Before doing this, X86 >> legalize would have to be very careful to specifically form shuffles >> that it knew isel would turn into (e.g.) unpck operations. Now >> instead of forming specific carefully constructed shuffle m...