[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