[all-commits] [llvm/llvm-project] 755c84: [RISCV] Avoid changing etype for splat of 0 or -1

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 755c84c62cda80b0acf51ccc5653fc6d64536f7e
      https://github.com/llvm/llvm-project/commit/755c84c62cda80b0acf51ccc5653fc6d64536f7e
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2022-06-17 (Fri, 17 Jun 2022)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
    M llvm/test/CodeGen/RISCV/rvv/constant-folding-crash.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-calling-conv.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-extload-truncstore.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-setcc.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp2i.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-unaligned.ll

  Log Message:
  -----------
  [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