[all-commits] [llvm/llvm-project] 7c7949: [SBVec] Add top-down vectorization to the unified ...

[Anshil Gandhi via All-commits]

  Branch: refs/heads/users/gandhi56/sandbox-vectorizer/topdown-vec
  Home:   https://github.com/llvm/llvm-project
  Commit: 7c7949ff481e74a8ef0f817ab4e1da1f2d864e9e
      https://github.com/llvm/llvm-project/commit/7c7949ff481e74a8ef0f817ab4e1da1f2d864e9e
  Author: Anshil Gandhi <gandhi21299 at gmail.com>
  Date:   2026-07-14 (Tue, 14 Jul 2026)

  Changed paths:
    M llvm/include/llvm/Transforms/Vectorize/SandboxVectorizer/Passes/BottomUpVec.h
    M llvm/include/llvm/Transforms/Vectorize/SandboxVectorizer/VecUtils.h
    M llvm/lib/Transforms/Vectorize/SandboxVectorizer/Passes/BottomUpVec.cpp
    M llvm/lib/Transforms/Vectorize/SandboxVectorizer/VecUtils.cpp
    M llvm/test/Transforms/SandboxVectorizer/external_uses.ll
    M llvm/test/Transforms/SandboxVectorizer/pack.ll
    A llvm/test/Transforms/SandboxVectorizer/topdown_vec.ll
    M llvm/unittests/Transforms/Vectorize/SandboxVectorizer/VecUtilsTest.cpp

  Log Message:
  -----------
  [SBVec] Add top-down vectorization to the unified Sandbox Vectorizer

Extend the Sandbox Vectorizer's `bottom-up-vec` pass so a single
implementation can vectorize in either direction, and add the top-down
strategy that walks def-use chains forward from a seed.

Direction selection
--------------------
The pass direction is chosen from the Region's auxiliary pass argument:
"bottom-up" (or empty, the default) and "top-down" map onto a
SchedDirection, and any other value is rejected with a fatal usage error.
The vectorizer always runs in the same direction as the scheduler.

Top-down traversal
------------------
Bottom-up starts from a seed slice (e.g. stores to consecutive addresses)
and recurses into operands. Top-down instead starts from a seed of
consecutive loads and recurses into *users*:

- vectorizeRec() registers the current bundle's vector (pre-order) before
  recursing, so instructions are marked vectorized as soon as they are
  claimed. This prevents sibling user bundles from claiming the same
  instruction and guarantees termination.
- VecUtils::getNextUserBundles() drives the walk. For each user of lane 0
  it tries to assemble a matching user for every remaining lane, requiring
  the same opcode, type, parent block, and operand-usage indices, and
  claiming each instruction at most once. Only complete bundles (one user
  per lane) are returned.
- A non-Widen legality result stops the walk down that path: the bundle is
  left scalar and no action is recorded. DiamondReuse results cannot occur
  top-down because already-vectorized users are skipped, so a bundle never
  contains an instruction already in InstrMaps.

Operand and external-use handling
---------------------------------
Because a user bundle is emitted after its operand bundle, emitVectors()
looks up each operand's vector in InstrMaps and creates a pack when the
operand was not vectorized. emitUnpacksForExternalUses() now redirects
only the genuinely external (non-vectorized) uses via replaceUsesWithIf(),
instead of a blanket replaceAllUsesWith() that would corrupt the operands
of user bundles not yet emitted. Scheduling is currently skipped for the
top-down direction (TODO).

Refactoring
-----------
Unify the two strategies to avoid code duplication: introduce a shared
BundleTy alias, move user-bundle collection into VecUtils (with unit
tests), and thread the direction through legality checks and vector
emission.

Co-authored-by: Cursor <cursoragent at cursor.com>



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