search for: splitvecres_binaryop

I have code that is generating sign extend in reg on a v8i32, but the backend does not support this data type. This then asserts in LegalizeVectorTypes.cpp:389 because there is no function to split this vector into smaller sizes. Would a correct solution be to add this case so to trigger the SplitVecRes_BinaryOp function? This asserts on both my backend and x86 and TOT does not seem to have any code to handle this. Thanks, Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091209/ce2b2166/attachment.html...

...at is generating sign extend in reg on a v8i32, but the > backend does not support this data type.  This then asserts in > LegalizeVectorTypes.cpp:389 because there is no function to split this > vector into smaller sizes. Would a correct solution be to add this case so > to trigger the SplitVecRes_BinaryOp function? SIGN_EXTEND_INREG isn't a binary operation; the correct expansion is expanding the first operand the same way SplitVecRes_BinaryOp does, while passing through the second operand untouched. But yes, adding a case to DAGTypeLegalizer::SplitVectorResult is the right idea. If anyone el...

...at is generating sign extend in reg on a v8i32, but the > backend does not support this data type.  This then asserts in > LegalizeVectorTypes.cpp:389 because there is no function to split this > vector into smaller sizes. Would a correct solution be to add this case so > to trigger the SplitVecRes_BinaryOp function? SIGN_EXTEND_INREG isn't a binary operation; the correct expansion is expanding the first operand the same way SplitVecRes_BinaryOp does, while passing through the second operand untouched. But yes, adding a case to DAGTypeLegalizer::SplitVectorResult is the right idea. If anyone el...

...n reg on a v8i32, but the > > backend does not support this data type.  This then asserts in > > LegalizeVectorTypes.cpp:389 because there is no function to split > this > > vector into smaller sizes. Would a correct solution be to add this > case so > > to trigger the SplitVecRes_BinaryOp function? > > SIGN_EXTEND_INREG isn't a binary operation; the correct expansion is > expanding the first operand the same way SplitVecRes_BinaryOp does, > while passing through the second operand untouched. But yes, adding a > case to DAGTypeLegalizer::SplitVectorResult is the...