[RISC-V] llvm.vp.select: Unexpected subvector extraction

[dkurt]

llc: /home/dkurt/llvm-project/llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp:1731: virtual void llvm::RISCVDAGToDAGISel::Select(llvm::SDNode*): Assertion `RISCVTargetLowering::getRegClassIDForVecVT(SubVecContainerVT) == InRegClassID && "Unexpected subvector extraction"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: /home/dkurt/llvm-16-build-riscv64-release/bin/llc -mtriple=riscv64 -target-abi=lp64d test_llvm.ll
1.      Running pass 'Function Pass Manager' on module 'test_llvm.ll'.
2.      Running pass 'RISCV DAG->DAG Pattern Instruction Selection' on function '@f0'
Segmentation fault

Command which I use on test_llvm.ll:

llc -mtriple=riscv64 -target-abi=lp64d test_llvm.ll

BTW, There is no overload with a mask for llvm.vp.select: https://llvm.org/docs/LangRef.html#llvm-vp-select-intrinsics. Can it help solve the problem?

[llvmbot]

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

[topperc]

I think the issue is that vscale_range has been set to 4 and vector.insert is being used to insert v8i32 vectors into nxv2i32 vectors without also putting +zvl256b in the target-features. So we have a disagreement about the minimum size of scalable vectors.

[dkurt]

@topperc, thanks, with llc -mtriple=riscv64 -mattr=+m,+a,+f,+d,+c,+v,+zvl256b -target-abi=lp64d test_llvm.ll it's compiled. May I ask a question if this is a problem in my code generator or this is LLVM issue?

[topperc]

@topperc, thanks, with llc -mtriple=riscv64 -mattr=+m,+a,+f,+d,+c,+v,+zvl256b -target-abi=lp64d test_llvm.ll it's compiled. May I ask a question if this is a problem in my code generator or this is LLVM issue?

I'm inclined to say it's a problem in your code generator. clang uses the Zvlb extensions to set the vscale_range. All of the backend code uses the Zvlb extension as well and not vscale_range. In your case you're setting vscale_range without setting Zvl*b.

Fixing this in LLVM might be possible by using vscale_range instead of Zvl*b in the backend. Or the larger of the two, but I'm not sure.

[topperc]

I'm working on a patch to make this work.(I need it for other reasons).

But I noticed the IR uses "vscale_range"="4, 4" instead of vscale_range(4, 4) in the attributes. The string version isn't recognized by any of the vscale_range parsing and is ignored.

[dkurt]

@topperc, thank you kindly. I'll keep on touch to test your solution.