This revision scalarizes extend/truncate for splat vector.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/test/CodeGen/RISCV/rvv/vfwmacc-sdnode.ll | ||
---|---|---|
28 ↗ | (On Diff #419646) | Any luck with these regressions? |
llvm/test/CodeGen/RISCV/rvv/vwsub-sdnode.ll | ||
2–3 | You need to re-add triple specific checks now that some of these test results diverge ; RUN: llc -mtriple=riscv32 -mattr=+v -verify-machineinstrs < %s | FileCheck %s --check-prefixes=CHECK,CHECK32 ; RUN: llc -mtriple=riscv64 -mattr=+v -verify-machineinstrs < %s | FileCheck %s --check-prefixes=CHECK,CHECK64 |
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
437 | I don't think UnOp is the right term here. UnaryOperator in IR is the base clang used by fneg. CastOp would probably be better. |
llvm/test/CodeGen/RISCV/rvv/vwsub-sdnode.ll | ||
---|---|---|
548 | regressions? |
llvm/test/CodeGen/RISCV/rvv/vwsub-sdnode.ll | ||
---|---|---|
548 | RISC-V is weak on scalar zero extend in the base ISA. We get a zext.w operation with the Zba extension. On the vector side a widening vwsub.wx is probably more expensive than a non-widening vsub.vx |
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
23537 | Should we be extracting from a SPLAT_VECTOR node like this or should we be accessing (and maybe truncating?) the N0.getOperand(0) directly? |
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
23537 | Thanks, I changed it to the latter one. |
Sorry, I'm a bit rusty. What happens with the equivalent fixed-length vector splats (BUILD_VECTOR)? If they're scalarized can we do the same for SPLAT_VECTOR in the same place? If they're not scalarized, what's the logic for only doing this transform for SPLAT_VECTOR?
llvm/test/CodeGen/RISCV/rvv/vnsra-sdnode.ll | ||
---|---|---|
33 | Still a regression - can RISCV64 really not be coaxed into generating something better? |
llvm/test/CodeGen/RISCV/rvv/vnsra-sdnode.ll | ||
---|---|---|
33 | In order to generate widening instruction, I disable scalarizing of sign_ext and zero_ext, because the scalar type integer extention is easy to combine with other node, make it won't match the pattern. |
cheers - its up to the RISCV guys as to whether this is acceptable (and whether it should be pulled out as a parent patch?)
llvm/test/CodeGen/RISCV/rvv/vnsra-sdnode.ll | ||
---|---|---|
33 | Do you think there's any way to fix it? |
llvm/test/CodeGen/RISCV/rvv/vnsra-sdnode.ll | ||
---|---|---|
33 | I think if we change the widen pattern to DAG combiner, maybe could generte some, but common DAG folder may fold extend to for others example: ext_inreg firstly. So more condition we need to consider |
@jacquesguan Please can you take a look at https://github.com/llvm/llvm-project/issues/62234 thats related to this patch?
I don't think UnOp is the right term here. UnaryOperator in IR is the base clang used by fneg. CastOp would probably be better.