<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Richard, <div><br></div><div><br><div><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">visitSIGN_EXTEND() in DAGCombiner.cpp generates an ISD::SELECT even if VT is a vector, which causes ExpandSELECT() to assert during legalization.<br>I think what's required is to have visitSIGN_EXTEND generate a VSELECT if VT is a vector…<br></div></blockquote><div><br></div><div>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().</div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><br>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.<br></div></blockquote><div><br></div><div>I think that replacing SELECT with VSELECT is the right thing to do. </div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">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 or i16 - all vectors of the same length, of course.)<br></div></blockquote><div><br></div><div>If I remember correctly the trick of expanding VSELECT into a sequence of XOR/AND/OR only works if the mask is known to be all-one or all-zero. </div><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><br>I don't really want to fix that, as the generated XOR/AND/AND/OR sequence isn't desirable at all for our target, which has an instruction that I think does precisely VSELECT…<br><br>Richard<br><br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a><span class="Apple-converted-space"> </span> <a href="http://llvm.cs.uiuc.edu/">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></div></blockquote></div><br></div></body></html>