search for: expandvselect

...ter, so I'm a bit uncertain if I'm heading off in the wrong direction. 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... The subsequent assert comes in ExpandVSELECT, which expects (for no good reason as far as I can tell) that the "mask" (really the 'selector') and the operands will be the same width, rather than trying to make them the same width (in our problem cases, the mask is an i32 produ...

...lve 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. > >>> The subsequent assert comes in ExpandVSELECT, which expects (for no good reason as far as I can tell) that the "mask" (really the 'selector') and the operands will be t...

...agree it is the right thing to do and it will help detect the problem sooner. 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. The assert at line 676 of LegalizeVectorOps.cpp… the Mask (operand 0) type is an i32, but Op1 is an i8. The subsequent assert comes in ExpandVSELECT, which expects (for no good reason as far as I can tel...

...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) that the "mask" (really the 'selector') and the operands will be the same width, rather than trying to make them the same width (in our problem cases, the mask is an i32 produced from getSetCCResultType() and the ops are i8...

...de(). > > 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. I think that replacing SELECT with VSELECT is the right thing to do. > The subsequent assert comes in ExpandVSELECT, which expects (for no good reason as far as I can tell) that the "mask" (really the 'selector') and the operands will be the same width, rather than trying to make them the same width (in our problem cases, the mask is an i32 produced from getSetCCResultType() and the ops are i8...

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 marked expand for vector types. I bet that just didn't get updates when VSELECT was introduced. > > -Jim > > On Oct 11, 2012, at 10:2...

> > 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]

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

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