[RISCV] Avoid changing etype for splat of 0 or -1
authorPhilip Reames <preames@rivosinc.com>
Fri, 17 Jun 2022 15:01:49 +0000 (08:01 -0700)
committerPhilip Reames <listmail@philipreames.com>
Fri, 17 Jun 2022 15:10:14 +0000 (08:10 -0700)
commit755c84c62cda80b0acf51ccc5653fc6d64536f7e
tree00ee71ae762ae841bba15e0e0dfe3d3efc09e265
parent4a3a9a5fa0b2fd0e70672c35010fe2f00740f098
[RISCV] Avoid changing etype for splat of 0 or -1

A splat of the values 0 and -1 as sign extended 12 bit immediates are always the same bit pattern regardless of the etype used to perform the operation. As a result, we can sometimes avoid introducing a vsetvli just for the purposes of a splat.

Looking at the diffs, we don't get a huge amount of immediate value out of this. We mostly push the vsetvli one instruction down, usually in front of a vmerge. We also don't get the corresponding fixed length vector cases because VL typically is changed despite the actual bits written being the same. Both of these are areas I plan to explore in future patches.

Interestingly, this makes a great example of why we need the forward and backward implementation to be consistent. Before we merged the demanded field handling, if we implement only the forward direction, we lost the ability to mutate a prior vsetvli and eliminate a later one entirely. This resulted in practical regressions instead of improvements. It's always nice when practice matches theory. :)

Differential Revision: https://reviews.llvm.org/D128006
llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
llvm/test/CodeGen/RISCV/rvv/constant-folding-crash.ll
llvm/test/CodeGen/RISCV/rvv/fixed-vectors-calling-conv.ll
llvm/test/CodeGen/RISCV/rvv/fixed-vectors-extload-truncstore.ll
llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-setcc.ll
llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp2i.ll
llvm/test/CodeGen/RISCV/rvv/fixed-vectors-unaligned.ll