[all-commits] [llvm/llvm-project] 422cf9: [VPlan] Only generate single instr for loads unifo...

[Florian Hahn via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 422cf99161ed5c34a32ce9ad549b5da29ad7906f
      https://github.com/llvm/llvm-project/commit/422cf99161ed5c34a32ce9ad549b5da29ad7906f
  Author: Florian Hahn <flo at fhahn.com>
  Date:   2022-09-08 (Thu, 08 Sep 2022)

  Changed paths:
    M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
    M llvm/test/Transforms/LoopVectorize/RISCV/uniform-load-store.ll
    M llvm/test/Transforms/LoopVectorize/X86/cost-model-assert.ll
    M llvm/test/Transforms/LoopVectorize/X86/uniform_mem_op.ll
    M llvm/test/Transforms/LoopVectorize/induction.ll
    M llvm/test/Transforms/LoopVectorize/pointer-select-runtime-checks.ll

  Log Message:
  -----------
  [VPlan] Only generate single instr for loads uniform across all parts.

VPReplicateRecipe::isUniform actually means uniform-per-parts, hence a
scalar instruction is generated per-part.

This is a potential alternative D132892. For now the current patch only
catches cases where the address is trivially invariant (defined outside
VPlan), while D132892 catches any address that is considered invariant
by SCEV AFAICT.

It should be possible to hoist fully invariant recipes feeding loads out
of the vector loop region as well, but in practice LICM should do that
already.

This version of the patch artificially limits this to loads to make it
easier to compare, but this restriction should be easily liftable.

Reviewed By: reames

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