[all-commits] [llvm/llvm-project] de423c: [RISCV] Prefer vsetivli for VLMAX when VLEN is exa...
Philip Reames via All-commits
all-commits at lists.llvm.org
Wed Jan 17 12:40:12 PST 2024
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: de423cfe3d5de0110b4f55ff1742988b529be6d2
https://github.com/llvm/llvm-project/commit/de423cfe3d5de0110b4f55ff1742988b529be6d2
Author: Philip Reames <preames at rivosinc.com>
Date: 2024-01-17 (Wed, 17 Jan 2024)
Changed paths:
M llvm/lib/Target/RISCV/RISCVISelLowering.cpp
M llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-extract-subvector.ll
M llvm/test/CodeGen/RISCV/rvv/load-add-store.ll
Log Message:
-----------
[RISCV] Prefer vsetivli for VLMAX when VLEN is exactly known (#75509)
If VLEN is exactly known, we may be able to use the vsetivli encoding
instead of the vsetvli a0, zero, <vtype> encoding. This slightly reduces
register pressure.
This builds on 632f1c5, but reverses course a bit. It turns out to be
quite complicated to canonicalize from VLMAX to immediate early because
the sentinel value is widely used in tablegen patterns without knowledge
of LMUL. Instead, we canonicalize towards the VLMAX representation, and
then pick the immediate form during insertion since we have the LMUL
information there.
Within InsertVSETVLI, this could reasonable fit in a couple places. If
reviewers want me to e.g. move it to emission, let me know. Doing so may
require a bit of extra code to e.g. handle comparisons of the two forms,
but shouldn't be too complicated.
More information about the All-commits
mailing list