Define vslideup/vslidedown intrinsics and lower to V instructions.
We work with @rogfer01 from BSC to come out this patch.
Authored-by: Roger Ferrer Ibanez <rofirrim@gmail.com>
Co-Authored-by: ShihPo Hung <shihpo.hung@sifive.com>
Paths
| Differential D93286
[RISCV] Define vslideup/vslidedown intrinsics and lower to V instructions. ClosedPublic Authored by arcbbb on Dec 15 2020, 1:33 AM.
Details Summary Define vslideup/vslidedown intrinsics and lower to V instructions. We work with @rogfer01 from BSC to come out this patch. Authored-by: Roger Ferrer Ibanez <rofirrim@gmail.com>
Diff Detail
Event TimelineHerald added subscribers: NickHung, luismarques, apazos and 24 others. · View Herald TranscriptDec 15 2020, 1:33 AM Comment Actions The destination register group for vslideup cannot overlap with the source vector register group, so I think we need an extra earlyclobber constraint passed to those pseudos. Comment Actions Please upload patches with git diff -U999999 so that we have full context. If I'm reading the spec correctly, the offset from the scalar register is not truncated to SEW before applying. So that means the ANY_EXTEND we use in LowerINTRINSIC_WO_CHAIN to extend the operand to XLenVT is incorrect for these intrinsics. We would need a ZERO_EXTEND instead. The C intrinsic spec defines them as taking size_t for offset. We should probably preserve that into the IR intrinsic.
Comment Actions Updates:
Thanks! This revision is now accepted and ready to land.Dec 18 2020, 1:49 PM Closed by commit rGd86a00d8febd: [RISCV] Define vslideup/vslidedown intrinsics (authored by arcbbb). · Explain WhyDec 20 2020, 5:09 AM This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 312971 llvm/include/llvm/IR/IntrinsicsRISCV.td
llvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td
llvm/test/CodeGen/RISCV/rvv/vslidedown-rv32.ll
llvm/test/CodeGen/RISCV/rvv/vslidedown-rv64.ll
llvm/test/CodeGen/RISCV/rvv/vslideup-rv32.ll
llvm/test/CodeGen/RISCV/rvv/vslideup-rv64.ll
|
Is the slideup/slidedown type always the same as the element type? Can we use LLVMVectorElementType<0> instead of llvm_any_ty?