This patch supports Zvfhmin for RISCV codegen.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
189 | Isn't the clang patch have dependent on this? |
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
189 | I ran the zvfhmin.c from the clang patch through CodeGen and got fatal error: error in backend: Scalarization of scalable vectors is not supported. The clang patch should be reverted until the CodeGen patch is in. |
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
1080 | This needs to be after By default everything must be expanded. |
llvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td | ||
---|---|---|
7038 | Nit: My mind is thinking of the sentence "this variable collects widen-able floating-point vectors that is widened from f16". I think the naming here didn't help me understand the code and I have actually read the RHS to understand the code here. Maybe we can improve this naming a nit. |
llvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td | ||
---|---|---|
7038 | Yes, and any suggestion about naming? |
llvm/test/CodeGen/RISCV/rvv/vfadd.ll | ||
---|---|---|
15 | Is there a plan to support this via promotion in a future patch? |
llvm/lib/Target/RISCV/RISCVFeatures.td | ||
---|---|---|
502 | nit: Mininal -> Minimal | |
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
907 | Need an isTypeLegal check? From the v-spec: When LMUL < SEW/ELEN, there is no guarantee an implementation would have enough bits in the fractional vector register to store at least one element, as VLEN=ELEN is a valid implementation choice. For example, with VLEN=ELEN=32, and SEWMIN=8, an LMUL of 1/8 would only provide four bits of storage in a vector register. Consider the scenario when VT is <vscale x 1 x 16>. Then LMUL=MF4. If VLEN=ELEN=32 then LMUL=MF4 would only provide 8 bits of storage in a vector register when 16 is needed. | |
llvm/lib/Target/RISCV/RISCVSubtarget.h | ||
169 | nit: Mininal -> Minimal |
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
909 | Need to make other fp arithmetic operations not available? We're just relying on isel to not select the instructions, but should we should not give ISel the freedom to do this. |
llvm/lib/Support/RISCVISAInfo.cpp | ||
---|---|---|
173 | This needs to be rebased, this list has been alphabetized. |
If I add RUN line with zvfhmin instead of zvfh llvm/test/CodeGen/RISCV/rvv/vfwnmacc-vp.ll, the compiler gives LLVM ERROR: Cannot select: t31: nxv1f32 = RISCVISD::VFWNMADD_VL t2, t4, t6, t8, t13, followed by trace. Probably need to check for zvfh in performVFMADD_VLCombine? Also maybe need to check in other functions like performFADDSUB_VLCombine?
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
911 | What is the reason not to use SetCommonVFPActions and SetCommonVFPExtLoadTruncStoreActions? I think we should be able to do all of these common VFP actions if we promote to f32 first. |
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
911 | Here is my patch for promoting f16 vector op zvfhmin https://reviews.llvm.org/D153848. As you say we can do all of these common VFP actions if we promote to f32 first, but then we have a f32 vector op and the action of it should be set under the f32 vector op scope which already used SetCommonVFPActions and SetCommonVFPExtLoadTruncStoreActions. |
Thanks to point it. I add a check to prevent the combination to widen op when we have only zvfhmin. But these test can not pass with RUN line zvfhmin because the vf form need promotion of splat, when implement in https://reviews.llvm.org/D153848.
No, actually the type promotion patch depends on this one. This patch added the basic support of zvfhmin which can only select to the several supported type convert instruction. https://reviews.llvm.org/D153848 uses promotion to support other ops.
I think that this patch and https://reviews.llvm.org/D153848 need to be committed at the same time. This will ensure that if the zvfhmin option is enabled, then we can codegen all LLVM IR.
I applied this patch and https://reviews.llvm.org/D153848, and then updated all instances of +zvfh to be +zvfhmin and re-ran the update_llc_test script for all of the files that were impacted. I found the following crash:
llvm/utils/update_llc_test_checks.py --llc-binary=build/bin/llc llvm/test/CodeGen/RISCV/regalloc-last-chance-recoloring-failure.ll LLVM ERROR: Cannot select: intrinsic %llvm.riscv.vfwsub.w PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: build/bin/llc -mtriple=riscv64 -mattr=+f,+m,+zfh,+zvfhmin -riscv-enable-subreg-liveness=false 1. Running pass 'Function Pass Manager' on module '<stdin>'. 2. Running pass 'RISC-V DAG->DAG Pattern Instruction Selection' on function '@last_chance_recoloring_failure' #0 0x000000000178f197 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (build/bin/llc+0x178f197) #1 0x000000000178cebe llvm::sys::RunSignalHandlers() (build/bin/llc+0x178cebe) #2 0x000000000178f9af SignalHandler(int) Signals.cpp:0:0 #3 0x00007f612c0b6cf0 __restore_rt (/lib64/libpthread.so.0+0x12cf0) #4 0x00007f612ab2aaff raise (/lib64/libc.so.6+0x4eaff) #5 0x00007f612aafdea5 abort (/lib64/libc.so.6+0x21ea5) #6 0x000000000170cad3 llvm::report_fatal_error(llvm::Twine const&, bool) (build/bin/llc+0x170cad3) #7 0x00000000015b1e3d llvm::SelectionDAGISel::CannotYetSelect(llvm::SDNode*) (build/bin/llc+0x15b1e3d) #8 0x00000000015b0cfb llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int) (build/bin/llc+0x15b0cfb) #9 0x000000000072465f llvm::RISCVDAGToDAGISel::Select(llvm::SDNode*) (build/bin/llc+0x72465f) #10 0x00000000015a60f5 llvm::SelectionDAGISel::DoInstructionSelection() (build/bin/llc+0x15a60f5) #11 0x00000000015a4fe2 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (build/bin/llc+0x15a4fe2) #12 0x00000000015a2b71 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (build/bin/llc+0x15a2b71) #13 0x000000000159f69c llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (build/bin/llc+0x159f69c) #14 0x0000000000be8e2c llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (build/bin/llc+0xbe8e2c) #15 0x0000000001102e23 llvm::FPPassManager::runOnFunction(llvm::Function&) (build/bin/llc+0x1102e23) #16 0x000000000110aaa1 llvm::FPPassManager::runOnModule(llvm::Module&) (build/bin/llc+0x110aaa1) #17 0x0000000001103626 llvm::legacy::PassManagerImpl::run(llvm::Module&) (build/bin/llc+0x1103626) #18 0x00000000006987e8 compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0 #19 0x00000000006962bd main (build/bin/llc+0x6962bd) #20 0x00007f612ab16d85 __libc_start_main (/lib64/libc.so.6+0x3ad85) #21 0x0000000000692c6e _start (build/bin/llc+0x692c6e)
I think we need to be able to update this patch or the type promotion patch to make sure we don't get any crashes like this when we run the experiment I describe above.
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
911 | Do we need this TODO still? | |
1092 | Do we need this TODO still? |
Yes, I agree with merging these patches at the same time.
But for the case regalloc-last-chance-recoloring-failure.ll, it uses the intirinsic @llvm.riscv.vfwsub.w.nxv16f32.nxv16f16.i64, this intrinsic is not supported in zvfhmin, so cannot selected is the excepted action. By example we also cannot select @llvm.riscv.vmulh.nxv1i64.i64 for ZVE64D, and any vector intrinsic for no V enable. I don't think we should do promotion for intrinsic too.
Actually target specific intrinsics basiclly comes from clang rvv-builtin. In https://reviews.llvm.org/D150253, any use of unsuportted builtin would cause a clang error. So there is no actual case will generate unsupportted intrinsic.
Yes, I agree with merging these patches at the same time.
But for the case regalloc-last-chance-recoloring-failure.ll, it uses the intirinsic @llvm.riscv.vfwsub.w.nxv16f32.nxv16f16.i64, this intrinsic is not supported in zvfhmin, so cannot selected is the excepted action. By example we also cannot select @llvm.riscv.vmulh.nxv1i64.i64 for ZVE64D, and any vector intrinsic for no V enable. I don't think we should do promotion for intrinsic too.
Actually target specific intrinsics basiclly comes from clang rvv-builtin. In https://reviews.llvm.org/D150253, any use of unsuportted builtin would cause a clang error. So there is no actual case will generate unsupportted intrinsic.
Thanks for the clarification. I agree with you now.
This needs to be rebased, this list has been alphabetized.