[all-commits] [llvm/llvm-project] 0b4761: [LV] Recognize store of invariant value to invaria...

Philip Reames via All-commits all-commits at lists.llvm.org
Tue Aug 2 08:10:26 PDT 2022


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0b47615fcf0cc93efe1a1cd6983e7208d2a0d915
      https://github.com/llvm/llvm-project/commit/0b47615fcf0cc93efe1a1cd6983e7208d2a0d915
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2022-08-02 (Tue, 02 Aug 2022)

  Changed paths:
    M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
    M llvm/test/Transforms/LoopVectorize/RISCV/scalable-tailfold.ll
    M llvm/test/Transforms/LoopVectorize/RISCV/uniform-load-store.ll
    M llvm/test/Transforms/LoopVectorize/X86/uniform_mem_op.ll
    M llvm/test/Transforms/LoopVectorize/pr47343-expander-lcssa-after-cfg-update.ll

  Log Message:
  -----------
  [LV] Recognize store of invariant value to invariant address as uniform

This extends the handling of uniform memory operations to handle the case where a store is storing a loop invariant value. Unlike the general case of a store to an invariant address where we must use the last active lane, in this case we can use any lane since all lanes must produce the same result.

For context, the basic structure of the existing code and how the change fits in:
* First, we select a widening strategy. (The result is irrelevant for this patch.)
* Then we determine if a computation is uniform within all lanes of VF. (Note this is the uniform-per-part definition, not LAI's uniform across all unrolled iterations definition.)
* If it is, we overrule the widening strategy, and unconditionally scalarize.
* VPReplicationRecipe - which is what actually does the scalarization - knows how to handle unform-per-part values including for scalable vectors. However, we do need to know that the expression is safe to execute without predication - e.g. the uniform mem op was unconditional in the original loop. (This part was split off and already landed.)

An obvious question is why not simply implement the generic case? The answer is that I'm going to, but doing so without a canonicalization towards uniform causes regressions due to bad interaction with scalarization/uniformity of values feeding the uniform mem-op. This patch is needed to avoid those regressions.

Differential Revision: https://reviews.llvm.org/D130364




More information about the All-commits mailing list