[all-commits] [llvm/llvm-project] b08e89: [VPlan] Consistently use (Part, 0) for first lane ...

[Florian Hahn via All-commits]

  Branch: refs/heads/users/fhahn/vplan-uniform-scalar-lanes
  Home:   https://github.com/llvm/llvm-project
  Commit: b08e8920ea23f2b4ce3bfe85af8878c81dfce28f
      https://github.com/llvm/llvm-project/commit/b08e8920ea23f2b4ce3bfe85af8878c81dfce28f
  Author: Florian Hahn <flo at fhahn.com>
  Date:   2024-02-01 (Thu, 01 Feb 2024)

  Changed paths:
    M llvm/lib/Transforms/Vectorize/VPlan.cpp
    M llvm/lib/Transforms/Vectorize/VPlan.h
    M llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp
    M llvm/test/Transforms/LoopVectorize/AArch64/masked-call.ll
    M llvm/test/Transforms/LoopVectorize/first-order-recurrence.ll

  Log Message:
  -----------
  [VPlan] Consistently use (Part, 0) for first lane scalar values

At the moment, some VPInstructions create only a single scalar value,
but use VPTransformatState's 'vector' storage for this value. Those
values are effectively uniform-per-VF (or in some cases
uniform-across-VF-and-UF). Using the vector/per-part storage doesn't
interact well with other recipes, that more accurately using (Part,
Lane) to look up scalar values and prevents VPInstructions creating
scalars from interacting with other recipes working with scalars.

This PR tries to unify handling of scalars by using (Part, 0) for scalar
values where only the first lane is demanded. This allows using
VPInstructions with other recipes like VPScalarCastRecipe and is also
needed when using VPInstructions in more cases otuside the vector loop
region to generate scalars.

The patch is still a bit rough around the edges, but hopefully serves as
start for a discussion how to model more scalar recipes. A potential
alternative would be to split off the opcodes that generate scalars only
to a separate recipe.