search for: vselect

Hello, We've run into a couple of cases where we'd like to use select on vector types, but vselect handling is absent from the ARM backend. Would there be any potential harm by marking VSELECT as Expand on ARM targets with NEON? Adding this seems to fix the following PR's: http://llvm.org/bugs/show_bug.cgi?id=13831 http://llvm.org/bugs/show_bug.cgi?id=13961 Thanks! Pete

If you mark VSELECT as 'expand' then it will be expanded to a sequence of AND/OR/XOR, which is pretty efficient (found in LegalizeVectorOps.cpp ExpandVSELECT). On Oct 11, 2012, at 11:05 AM, Jim Grosbach <grosbach at apple.com> wrote: > Seems reasonable to me. Plain 'SELECT' is already marke...

Seems reasonable to me. Plain 'SELECT' is already marked expand for vector types. I bet that just didn't get updates when VSELECT was introduced. -Jim On Oct 11, 2012, at 10:25 AM, Peter Couperus <peter.couperus at st.com> wrote: > Hello, > > We've run into a couple of cases where we'd like to use select on vector types, but vselect handling is absent from the ARM backend. > Would there be any po...

Hi @ll, I am wondering about the use of !isBeforeLegalize in PerformSELECTCombine in the X86 backend. This defers all VSELECT related DAG combines until after the Legalizer has run. If the IR has already only legal types the second round of DAG combines is skipped and no VSELECT specified optimizations are performed at all. Is there a reason we don’t run the X86 DAG combiner before Type Legalization? Thanks Cheers, Jue...

...ompiling the code with vector type with some architecture. IR is as following. %cmp = icmp sgt <3 x i8> %x, zeroinitializer %sub = sub <3 x i8> zeroinitializer, %x %cond = select <3 x i1> %cmp, <3 x i8> %x, <3 x i8> %sub 'select' IR is converted to 'vselect' dag and is combined to 'sra (X, size(X)-1); xor (add (X, Y), Y)'. There is a problem here. If the target support i8 type as promote integer to make size(X), size(X) has i32 type. and then type legalize pass do widening the vector like this. v4i8 = BUILD_VECTOR 0x99d90a8: i32 = Const...

..., 2013, at 4:13 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Mon, Aug 19, 2013 at 3:34 PM, Juergen Ributzka <juergen at apple.com> wrote: > Hi @ll, > > I am wondering about the use of !isBeforeLegalize in PerformSELECTCombine in the X86 backend. This defers all VSELECT related DAG combines until after the Legalizer has run. If the IR has already only legal types the second round of DAG combines is skipped and no VSELECT specified optimizations are performed at all. > > Is there a reason we don’t run the X86 DAG combiner before Type Legalization? > >...

Can this optimization be moved to the lowering phase? LowerVSELECT() ? - Elena From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Tuesday, August 20, 2013 03:56 To: Juergen Ributzka Cc: Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] [X86] DAG Combine - VSELECT On Mon, Aug...

...dman <eli.friedman at gmail.com> wrote: > > On Mon, Aug 19, 2013 at 3:34 PM, Juergen Ributzka <juergen at apple.com>wrote: > >> Hi @ll, >> >> I am wondering about the use of !isBeforeLegalize in PerformSELECTCombine >> in the X86 backend. This defers all VSELECT related DAG combines until >> after the Legalizer has run. If the IR has already only legal types the >> second round of DAG combines is skipped and no VSELECT specified >> optimizations are performed at all. >> >> Is there a reason we don’t run the X86 DAG combiner be...

Hello, I am getting this error. What instruction is required to be implemented? LLVM ERROR: Cannot select: t22: v32i32 = vselect t724, t11, t16 t724: v32i32,ch = load<LD128[FixedStack1]> t723, FrameIndex:i64<1>, undef:i64 t659: i64 = FrameIndex<1> t10: i64 = undef t11: v32i32,ch = load<LD128[%sunkaddr45](align=4)(tbaa=<0x481f1e8>)> t0, t8, undef:i64 t8: i64 = add t7, Constant:i64...

...ith some > architecture. IR is as following. > > %cmp = icmp sgt <3 x i8> %x, zeroinitializer > %sub = sub <3 x i8> zeroinitializer, %x > %cond = select <3 x i1> %cmp, <3 x i8> %x, <3 x i8> %sub > > 'select' IR is converted to 'vselect' dag and is combined to 'sra (X, > size(X)-1); xor (add (X, Y), Y)'. There is a problem here. If the target support > i8 type as promote integer to make size(X), size(X) has i32 type. and then type > legalize pass do widening the vector like this. > > v4i8 = BUILD_VECT...

Hello. Because I experience optimizations (DCE, OoO schedule) which mess the correct semantics of the list of instructions lowered in ISelLowering from the VSELECT LLVM instruction, and these bad transformations happen even before scheduling, at later I-sel subpasses, I try to fix this problem by lowering VSELECT to only one pseudo-instruction and LATER translate it to a list of instructions and use bundles and maybe also PredicateInstruction(), which is...

On Mon, Aug 19, 2013 at 3:34 PM, Juergen Ributzka <juergen at apple.com> wrote: > Hi @ll, > > I am wondering about the use of !isBeforeLegalize in PerformSELECTCombine > in the X86 backend. This defers all VSELECT related DAG combines until > after the Legalizer has run. If the IR has already only legal types the > second round of DAG combines is skipped and no VSELECT specified > optimizations are performed at all. > > Is there a reason we don’t run the X86 DAG combiner before Type > Legal...

visitSIGN_EXTEND() in DAGCombiner.cpp generates an ISD::SELECT even if VT is a vector, which causes ExpandSELECT() to assert during legalization. I think what's required is to have visitSIGN_EXTEND generate a VSELECT if VT is a vector… I've tried a local change that cures this particular assert, but uncovers another assert later, so I'm a bit uncertain if I'm heading off in the wrong direction. The subsequent assert comes in ExpandVSELECT, which expects (for no good reason as far as I can tell) tha...

...the SIGN_EXTEND, we generate the ISD::SELECT even though the selector and both operands are vectors. It sounds like a bug in the dag combine optimization. If you send me the line number I will take a look. Line 4501 in trunk DAGCombiner.cpp… I changed the ISD::SELECT to the VT.isVector() ? ISD::VSELECT : ISD::SELECT... We should probably add an assert in SelectionDAG::getNode(). I've tried a local change that cures this particular assert, but uncovers another assert later, so I'm a bit uncertain if I'm heading off in the wrong direction. Adding assertions to getNode is the right t...

...m <nrotem at apple.com<mailto:nrotem at apple.com>> wrote: Hi Richard, visitSIGN_EXTEND() in DAGCombiner.cpp generates an ISD::SELECT even if VT is a vector, which causes ExpandSELECT() to assert during legalization. I think what's required is to have visitSIGN_EXTEND generate a VSELECT if VT is a vector… ISD::SELECT should be used for cases where the selector is a scalar, even if the operands are vector. If you found a case where SELECT is used with a vector operand then this is a bug. I did… It originates from an icmp ne <2x i8>, zero initializer followed by a sext of th...

Hi Richard, > visitSIGN_EXTEND() in DAGCombiner.cpp generates an ISD::SELECT even if VT is a vector, which causes ExpandSELECT() to assert during legalization. > I think what's required is to have visitSIGN_EXTEND generate a VSELECT if VT is a vector… ISD::SELECT should be used for cases where the selector is a scalar, even if the operands are vector. If you found a case where SELECT is used with a vector operand then this is a bug. We should probably add an assert in SelectionDAG::getNode(). > > I've tried a loca...

...vers another assert later, so I'm a bit uncertain if I'm heading off in the wrong direction. >> Adding assertions to getNode is the right thing to do. I am not sure that it will solve your problem, but it will help us some some problems. >> I think that replacing SELECT with VSELECT is the right thing to do. > > VT.isVector() ? ISD::VSELECT : ISD::SELECT in lieu of the fixed ISD::SELECT seems to do the trick for me. Except that it sometimes hits the assert in ExpandVSELECT… Okay. Which assertion in ExpandVSELECT fail ? Maybe our assumptions there are incorrect. &gt...

> > Line 4501 in trunk DAGCombiner.cpp… I changed the ISD::SELECT to the VT.isVector() ? ISD::VSELECT : ISD::SELECT... > Thanks. From the commit message I think that we should only run this optimization on scalars. >> Can you write down the input SDNode ? What types are inputs ? > > 0x107046d10: v2i8 = vselect 0x107046c10, 0x107046b10, 0x107045e10 [ID=-3] > >...

..."$dst = $oldvalue" in { > def MASKEDARITH : MyInstruction< > (outs VectorReg:$dst), > (ins MaskReg:$mask, VectorReg:$src1, VectorReg:$src2, > VectorReg:$oldvalue), > "add $dst {$mask}, $src1, $src2", > [(set v16i32:$dst, (vselect v16i1:$mask, (add v16i32:$src1, > v16i32:$src2), v16i32:$oldvalue))]>; > } Ok, but where does $oldvalue come from? That is the trickty part as far as I can see and is why this isn't quite the same as handling two-address instructions. I agree that the pattern itself is straightforwa...

Hi Rotem, What do you mean by "you can use the <4 x float> type for which the vselect works". Do you mean that then back-end can correctly split the operands when it is a four elements vector? I've try that, but it still fails. On Wed, Oct 19, 2011 at 4:21 PM, Rotem, Nadav <nadav.rotem at intel.com> wrote: > This is indeed a bug. I get a different error on my ma...