[RISCV] "Don't know how to widen the operands for INSERT_SUBVECTOR"

[steven-johnson]

The enclosed .ll file crashes when run through top-of-tree llc; here is the Issue and stacktrace, as requested by the crash message:

$ ~/llvm-17-install/bin/llc /tmp/insert_subvector.ll -o /tmp/foof
LLVM ERROR: Don't know how to widen the operands for INSERT_SUBVECTOR
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: /usr/local/google/home/srj/llvm-17-install/bin/llc /tmp/insert_subvector.ll -o /tmp/foof
1.	Running pass 'Function Pass Manager' on module '/tmp/insert_subvector.ll'.
2.	Running pass 'RISC-V DAG->DAG Pattern Instruction Selection' on function '@_Z16insert_subvectorP15halide_buffer_tS0_bS0_'
 #0 0x0000563174316e3b llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/google/home/srj/llvm-17-install/bin/llc+0x2a8fe3b)
 #1 0x00005631743147cb llvm::sys::RunSignalHandlers() (/usr/local/google/home/srj/llvm-17-install/bin/llc+0x2a8d7cb)
 #2 0x00005631743148f5 SignalHandler(int) Signals.cpp:0:0
 #3 0x00007fb9a297bf90 (/lib/x86_64-linux-gnu/libc.so.6+0x3bf90)
 #4 0x00007fb9a29caccc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #5 0x00007fb9a297bef2 raise ./signal/../sysdeps/posix/raise.c:27:6
 #6 0x00007fb9a2966472 abort ./stdlib/abort.c:81:7
 #7 0x0000563171f31b91 (/usr/local/google/home/srj/llvm-17-install/bin/llc+0x6aab91)
 #8 0x0000563174274eea (/usr/local/google/home/srj/llvm-17-install/bin/llc+0x29edeea)
 #9 0x00005631741b581c llvm::DAGTypeLegalizer::WidenVecOp_INSERT_SUBVECTOR(llvm::SDNode*) (/usr/local/google/home/srj/llvm-17-install/bin/llc+0x292e81c)
#10 0x00005631741cb1bc llvm::DAGTypeLegalizer::WidenVectorOperand(llvm::SDNode*, unsigned int) (/usr/local/google/home/srj/llvm-17-install/bin/llc+0x29441bc)
#11 0x0000563174176221 llvm::DAGTypeLegalizer::run() (/usr/local/google/home/srj/llvm-17-install/bin/llc+0x28ef221)
#12 0x00005631741773b8 llvm::SelectionDAG::LegalizeTypes() (/usr/local/google/home/srj/llvm-17-install/bin/llc+0x28f03b8)
#13 0x00005631740ea7b0 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/usr/local/google/home/srj/llvm-17-install/bin/llc+0x28637b0)
#14 0x00005631740ee980 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/usr/local/google/home/srj/llvm-17-install/bin/llc+0x2867980)
#15 0x00005631740f0377 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (.part.0) SelectionDAGISel.cpp:0:0
#16 0x00005631735ab7bf llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#17 0x0000563173b46cc9 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/google/home/srj/llvm-17-install/bin/llc+0x22bfcc9)
#18 0x0000563173b46e01 llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/local/google/home/srj/llvm-17-install/bin/llc+0x22bfe01)
#19 0x0000563173b47717 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/google/home/srj/llvm-17-install/bin/llc+0x22c0717)
#20 0x0000563171fdfffc compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#21 0x0000563171f36997 main (/usr/local/google/home/srj/llvm-17-install/bin/llc+0x6af997)
#22 0x00007fb9a296718a __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
#23 0x00007fb9a2967245 call_init ./csu/../csu/libc-start.c:128:20
#24 0x00007fb9a2967245 __libc_start_main ./csu/../csu/libc-start.c:368:5
#25 0x0000563171fd6851 _start (/usr/local/google/home/srj/llvm-17-install/bin/llc+0x74f851)
Aborted

insert_subvector.ll.zip

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

[lukel97]

Thanks for the reproducer, here's it reduced:

define <vscale x 2 x i8> @f(<3 x i8> %v) {
  %res = tail call <vscale x 2 x i8> @llvm.vector.insert.nxv2i8.v3i8(<vscale x 2 x i8> poison, <3 x i8> %v, i64 0)
  ret <vscale x 2 x i8> %res
}

declare <vscale x 2 x i8> @llvm.vector.insert.nxv2i8.v3i8(<vscale x 2 x i8>, <3 x i8>, i64)

[lukel97]

Created patch at https://reviews.llvm.org/D153519

[lukel97]

The patch in https://reviews.llvm.org/D153519 should handle the case where we know we can safely widen the operand given a suitable vscale_range attribute, but the attached test case still crashes because the vscale_range attribute is formatted as a string, i.e. of "vscale_range" = "2, 2" instead of vscale_range(2,2), and so it isn't parsed. Could you try recompiling the case from clang or whatever frontend in case the attribute somehow changed in the meantime?