search for: lowervector_shuffle

In ToT, LowerVECTOR_SHUFFLE for x86 has this code: if (X86::isUNPCKLMask(SVOp)) getTargetShuffleNode(getUNPCKLOpcode(VT) dl, VT, V1, V2, DAG); why would this not be: if (X86::isUNPCKLMask(SVOp)) return SVOp; I'm trying to add support for VUNPCKL and am getting into trouble because the existing code ends up...

David Greene <dag at cray.com> writes: > In ToT, LowerVECTOR_SHUFFLE for x86 has this code: > > if (X86::isUNPCKLMask(SVOp)) > getTargetShuffleNode(getUNPCKLOpcode(VT) dl, VT, V1, V2, DAG); > > why would this not be: > > if (X86::isUNPCKLMask(SVOp)) > return SVOp; Ok, I discovered that Bruno did this in revisions 112934, 112942 a...

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

...may stop being legal and break isel. By legalizing to target-specific DAG nodes, we avoid that possibility and also make it much easier to match the shuffles during isel. On Feb 25, 2011, at 6:01 PM, David A. Greene wrote: > David Greene <dag at cray.com> writes: > >> In ToT, LowerVECTOR_SHUFFLE for x86 has this code: >> >> if (X86::isUNPCKLMask(SVOp)) >> getTargetShuffleNode(getUNPCKLOpcode(VT) dl, VT, V1, V2, DAG); >> >> why would this not be: >> >> if (X86::isUNPCKLMask(SVOp)) >> return SVOp; > > Ok, I discovered that Bru...

Bob Wilson <bob.wilson at apple.com> writes: > It is inefficient and error-prone to recognize legal shuffles and then > have isel repeat the process. For example, if the DAG combiner > changes a shuffle in between legalization and isel, it may stop being > legal and break isel. By legalizing to target-specific DAG nodes, we > avoid that possibility and also make it much

> 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 legalization and also more than once in the tablegen

Bruno Cardoso Lopes <bruno.cardoso at gmail.com> writes: >> It really doesn't seem worth it to me. > > 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

> 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

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

...ufp : 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<int> &M, EVT VT) const { // FIXME: pshufb, blends, shifts. return (VT.getVectorNumElements() == 2 ||...

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

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...SelectionDAG &DAG); + std::pair<SDValue,SDValue> FP_TO_INTHelper(SDValue Op, SelectionDAG &DAG, + bool isSigned); SDValue LowerBUILD_VECTOR(SDValue Op, SelectionDAG &DAG); SDValue LowerVECTOR_SHUFFLE(SDValue Op, SelectionDAG &DAG); @@ -586,11 +586,16 @@ SDValue LowerGlobalTLSAddress(SDValue Op, SelectionDAG &DAG); SDValue LowerExternalSymbol(SDValue Op, SelectionDAG &DAG); SDValue LowerShift(SDValue Op, SelectionDAG &DAG); + SDValue BuildFILD(SDValue Op, MVT Sr...