[all-commits] [llvm/llvm-project] bc8dad: [VPlan] Emit VPVectorEndPointerRecipe for reverse ...

[Mel Chen via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: bc8dad1c7ef02f9a9d8a07c242fc3db470a7579b
      https://github.com/llvm/llvm-project/commit/bc8dad1c7ef02f9a9d8a07c242fc3db470a7579b
  Author: Mel Chen <mel.chen at sifive.com>
  Date:   2025-07-02 (Wed, 02 Jul 2025)

  Changed paths:
    M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
    M llvm/lib/Transforms/Vectorize/VPlan.h
    M llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp
    M llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp
    M llvm/test/Transforms/LoopVectorize/AArch64/sve-interleaved-accesses.ll
    M llvm/test/Transforms/LoopVectorize/RISCV/riscv-vector-reverse-output.ll
    M llvm/test/Transforms/LoopVectorize/RISCV/riscv-vector-reverse.ll
    M llvm/test/Transforms/LoopVectorize/RISCV/vectorize-force-tail-with-evl-reverse-load-store.ll
    M llvm/test/Transforms/LoopVectorize/RISCV/vectorize-force-tail-with-evl-uniform-store.ll

  Log Message:
  -----------
  [VPlan] Emit VPVectorEndPointerRecipe for reverse interleave pointer adjustment (#144864)

A reverse interleave access is essentially composed of multiple
load/store operations with same negative stride, and their addresses are
based on the last lane address of member 0 in the interleaved group.

Currently, we already have VPVectorEndPointerRecipe for computing the
last lane address of consecutive reverse memory accesses. This patch
extends VPVectorEndPointerRecipe to support constant stride and extracts
the reverse interleave group address adjustment from
VPInterleaveRecipe::execute, replacing it with a
VPVectorEndPointerRecipe.

The final goal is to support interleaved accesses with EVL tail folding.
Given that VPInterleaveRecipe is large and tightly coupled — combining
both load and store, and embedding operations like reverse pointer
adjustion (GEP), widen load/store, deinterleave/interleave, and reversal
— breaking it down into smaller, dedicated recipes may allow
VPlanTransforms::tryAddExplicitVectorLength to lower them into EVL-aware
form more effectively.

One foreseeable challenge is that
VPlanTransforms::convertToConcreteRecipes currently runs after
tryAddExplicitVectorLength, so decomposing VPInterleaveRecipe will
likely need to happen earlier in the pipeline to be effective.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications