search for: splitvectorresult

I'm getting this on LLVM trunk: SplitVectorResult #0: 0x27e6250: v8f32 = llvm.x86.avx.rsqrt.ps.256 0x2739310, 0x2739420 [ORD=16] [ID=0] LLVM ERROR: Do not know how to split the result of this operator! clang: error: linker command failed with exit code 1 (use -v to see invocation) Oddly, when I build the same code without -flto I don't see th...

...m.neon.vmaxs.v16f32(<16 x float> %tmp1, <16 x float> %tmp2) store <16 x float> %tmp3, <16 x float>* %C ret void } declare <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float>, <16 x float>) nounwind readnone llc fails with following message: SplitVectorResult #0: 0x2258350: v16f32 = llvm.arm.neon.vmaxs 0x2258250, 0x2258050, 0x2258150 [ORD=3] [ID=0] LLVM ERROR: Do not know how to split the result of this operator! Is it a BUG ? If yes I'm happy to get some directions on how I can fix it. If not I would like to know how to determine valid type for a...

...s 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 else is curious, here's a testcase which crashes on x86 when llc is run over it: define <8 x i32> @a(<8 x i32> %a) { %b = trunc <8 x i32> %a to <8 x i16> %c = sext <8 x i16> %b to <8 x i32> ret <8 x i32> %c } -Eli

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

...%tmp1, <16 x float> %tmp2) > store <16 x float> %tmp3, <16 x float>* %C > ret void > } > > declare <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float>, <16 x float>) nounwind readnone > > llc fails with following message: > > SplitVectorResult #0: 0x2258350: v16f32 = llvm.arm.neon.vmaxs 0x2258250, 0x2258050, 0x2258150 [ORD=3] [ID=0] > > LLVM ERROR: Do not know how to split the result of this operator! > > Is it a BUG ? If yes I'm happy to get some directions on how I can fix it. No... platform-specific intrinsics have pl...

On 21 September 2012 09:28, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote: > declare <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float>, <16 x float>) nounwind readnone > > llc fails with following message: > > SplitVectorResult #0: 0x2258350: v16f32 = llvm.arm.neon.vmaxs 0x2258250, 0x2258050, 0x2258150 [ORD=3] [ID=0] > > LLVM ERROR: Do not know how to split the result of this operator! > > Is it a BUG ? If yes I'm happy to get some directions on how I can fix it. If not I would like to know how to determin...

...%tmp1, <16 x float> %tmp2) > store <16 x float> %tmp3, <16 x float>* %C > ret void > } > > declare <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float>, <16 x float>) nounwind readnone > > llc fails with following message: > > SplitVectorResult #0: 0x2258350: v16f32 = llvm.arm.neon.vmaxs 0x2258250, 0x2258050, 0x2258150 [ORD=3] [ID=0] > > LLVM ERROR: Do not know how to split the result of this operator! > > Is it a BUG ? If yes I'm happy to get some directions on how I can fix it. No... platform-specific intrinsics have pl...

...s 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 else is curious, here's a testcase which crashes on x86 when llc is run over it: define <8 x i32> @a(<8 x i32> %a) { %b = trunc <8 x i32> %a to <8 x i16> %c = sext <8 x i16> %b to <8 x i32> ret <8 x i32> %c } -Eli

...;> store <16 x float> %tmp3, <16 x float>* %C >> ret void >> } >> >> declare <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float>, <16 x float>) nounwind readnone >> >> llc fails with following message: >> >> SplitVectorResult #0: 0x2258350: v16f32 = llvm.arm.neon.vmaxs 0x2258250, 0x2258050, 0x2258150 [ORD=3] [ID=0] >> >> LLVM ERROR: Do not know how to split the result of this operator! >> >> Is it a BUG ? If yes I'm happy to get some directions on how I can fix it. > > No... platform...

Hello, I have a kernel that's swizzling a vector inside a loop. The vector was created before the loop. The first node in the dag is an extract subvector which calls into SplitVectorOp. The issue is that the node passed to it comes from a CopyFromReg and SplitVectorOp doesn't know what to do. Is there a reason why SplitVectorOp doesn't handle CopyFromReg nodes? If not, can I submit a

Hi Javier, > I have a kernel that's swizzling a vector inside a loop. The vector was > created before the loop. The first node in the dag is an extract subvector > which calls into SplitVectorOp. The issue is that the node passed to it > comes from a CopyFromReg and SplitVectorOp doesn't know what to do. Is > there a reason why SplitVectorOp doesn't handle CopyFromReg

...x00007f1b359326ec (/home/dev/llvm/build/bin/../lib/libLLVMHexagonCodeGen.so.6+0x1176ec) #8 0x00007f1b2d6a37a6 llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, llvm::EVT, bool) (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1247a6) #9 0x00007f1b2d6be0d9 llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, unsigned int) (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x13f0d9) #10 0x00007f1b2d69f156 llvm::DAGTypeLegalizer::run() (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x120156) #11 0x00007f1b2d6a01ff llvm::SelectionDAG::LegalizeTypes() (/home/dev/llvm/bui...

...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 else is curious, here's a testcase which crashes on x86 when > llc is run over it: > define <8 x i32> @a(<8 x i32> %a) { > %b = trunc <8 x i32> %a to <8 x i16> > %c = sext <8 x i16> %b to <8 x i32> >...

...ome/dev/llvm/build/bin/../lib/libLLVMHexagonCodeGen.so.6+0x1176ec) > #8 0x00007f1b2d6a37a6 > llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, llvm::EVT, bool) > (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1247a6) > #9 0x00007f1b2d6be0d9 > llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, unsigned int) > (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x13f0d9) > #10 0x00007f1b2d69f156 llvm::DAGTypeLegalizer::run() > (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x120156) > #11 0x00007f1b2d6a01ff llvm::SelectionDAG::LegalizeTypes() &g...

...in/../lib/libLLVMHexagonCodeGen.so.6+0x1176ec) > #8 0x00007f1b2d6a37a6 > llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, llvm::EVT, bool) > (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1247a6) > #9 0x00007f1b2d6be0d9 > llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, unsigned int) > (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x13f0d9) > #10 0x00007f1b2d69f156 llvm::DAGTypeLegalizer::run() > (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x120156) > #11 0x00007f1b2d6a01ff llvm::SelectionDAG::Le...

...> 6+0x1176ec) > > #8 0x00007f1b2d6a37a6 > > llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, llvm::EVT, > bool) > > (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1247a6) > > #9 0x00007f1b2d6be0d9 > > llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, unsigned > int) > > (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x13f0d9) > > #10 0x00007f1b2d69f156 llvm::DAGTypeLegalizer::run() > > (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x120156) > > #11 0x00007f1b2d6a01...

...Question about LLVM NEON intrinsics On 21 September 2012 09:28, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote: > declare <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float>, <16 x float>) nounwind readnone > > llc fails with following message: > > SplitVectorResult #0: 0x2258350: v16f32 = llvm.arm.neon.vmaxs 0x2258250, 0x2258050, 0x2258150 [ORD=3] [ID=0] > > LLVM ERROR: Do not know how to split the result of this operator! > > Is it a BUG ? If yes I'm happy to get some directions on how I can fix it. If not I would like to know how to determin...

...0x00007f1b2d6a37a6 > >     llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, > llvm::EVT, bool) > > >  (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1247a6) > >     #9 0x00007f1b2d6be0d9 > >     llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, > unsigned int) > > >  (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x13f0d9) > >     #10 0x00007f1b2d69f156 llvm::DAGTypeLegalizer::run() > > >  (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x120...

For the tests that are changing, you should see if those changes are improvements, regressions, or neutral. This is unfortunately not always obvious for x86 asm, so feel free to just post those diffs in an updated version of the patch at D37896. If the test files have auto-generated assertions (look for this string on the first line of the test file: "NOTE: Assertions have been autogenerated