[all-commits] [llvm/llvm-project] 1733c1: [NFC][VPlan] Split `makeMemOpWideningDecisions` in...

Andrei Elovikov via All-commits all-commits at lists.llvm.org
Tue Apr 14 13:57:47 PDT 2026


  Branch: refs/heads/users/eas/mem-widen-subpasses
  Home:   https://github.com/llvm/llvm-project
  Commit: 1733c13978c3e9cf499e2c6bb119ccdf572e6109
      https://github.com/llvm/llvm-project/commit/1733c13978c3e9cf499e2c6bb119ccdf572e6109
  Author: Andrei Elovikov <andrei.elovikov at sifive.com>
  Date:   2026-04-14 (Tue, 14 Apr 2026)

  Changed paths:
    M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
    M llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp
    M llvm/lib/Transforms/Vectorize/VPlanTransforms.h
    M llvm/test/Transforms/LoopVectorize/VPlan/vplan-print-after-all.ll

  Log Message:
  -----------
  [NFC][VPlan] Split `makeMemOpWideningDecisions` into subpasses

The idea is to have handling of strided memory operations (either from
https://github.com/llvm/llvm-project/pull/147297 or for VPlan-based
multiversioning for unit-strided accesses) done after some mandatory
processing has been performed (e.g., some types **must** be scalarized)
but before legacy CM's decision to widen (gather/scatter) or scalarize
has been committed.

And in longer term, we can uplift all other memory widening decision to
be done here directly at VPlan level. I expect this structure would also
be beneficial for that.



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


More information about the All-commits mailing list