[all-commits] [llvm/llvm-project] 0c73a5: [RISCV] Starting fixing issues that prevent us fro...
Craig Topper via All-commits
all-commits at lists.llvm.org
Wed Mar 10 09:46:01 PST 2021
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: 0c73a506e809be24e043856259fc07cef64f02b0
https://github.com/llvm/llvm-project/commit/0c73a506e809be24e043856259fc07cef64f02b0
Author: Craig Topper <craig.topper at sifive.com>
Date: 2021-03-10 (Wed, 10 Mar 2021)
Changed paths:
M llvm/include/llvm/IR/IntrinsicsRISCV.td
M llvm/lib/Target/RISCV/RISCVISelLowering.cpp
M llvm/lib/Target/RISCV/RISCVISelLowering.h
M llvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td
M llvm/test/CodeGen/RISCV/rvv/vaadd-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vaaddu-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vadc-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vadd-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vand-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vasub-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vasubu-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vmv.s.x-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vmv.v.x-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vnsra-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vnsrl-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vssra-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vssrl-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vwadd-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vwaddu-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vwaddu.w-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vwsub-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vwsubu-rv32.ll
M llvm/test/CodeGen/RISCV/rvv/vwsubu.w-rv32.ll
Log Message:
-----------
[RISCV] Starting fixing issues that prevent us from testing vXi64 intrinsics on RV32.
Currently we crash in type legalization any time an intrinsic
uses a scalar i64 on RV32.
This patch adds support for type legalizing this to prevent
crashing. I don't promise that it uses the best possible codegen
just that it is functional.
This first version handles 3 cases. vmv.v.x intrinsic, vmv.s.x
intrinsic and intrinsics that take a scalar input, splat it and
then do some operation.
For vmv.v.x we'll either rely on hardware sign extension for
constants or we'll convert it to multiple splats and bit
manipulation.
For vmv.s.x we use a really unoptimal sequence inspired by what
we do for an INSERT_VECTOR_ELT.
For the third case we'll either try to use the .vi form for
constants or convert to a complicated splat and bitmanip and use
the .vv form of the operation.
I've renamed the ExtendOperand field to SplatOperand now use it
specifically for the third case. The first two cases are handled
by custom lowering specifically for those intrinsics.
I haven't updated all tests yet, but I tried to cover a subset
that includes single-width, widening, and narrowing.
Reviewed By: frasercrmck
Differential Revision: https://reviews.llvm.org/D97895
More information about the All-commits
mailing list