[all-commits] [llvm/llvm-project] f709fb: [SROA] Only try additional vector type candidates ...

[Jeffrey Byrnes via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f709fbb1bb5e6240aad4edeb2f0e417df74cfa27
      https://github.com/llvm/llvm-project/commit/f709fbb1bb5e6240aad4edeb2f0e417df74cfa27
  Author: Jeffrey Byrnes <jeffrey.byrnes at amd.com>
  Date:   2024-01-23 (Tue, 23 Jan 2024)

  Changed paths:
    M llvm/lib/Transforms/Scalar/SROA.cpp
    M llvm/test/Transforms/SROA/vector-promotion.ll

  Log Message:
  -----------
  [SROA] Only try additional vector type candidates when needed (#77678)

https://github.com/llvm/llvm-project/commit/f9c2a341b94ca71508dcefa109ece843459f7f13
causes regressions when we have a slice with integer vector type that is
the same size as the partition, and a ptr load/store slice that is not
the size of the element type.

Ref `vector-promotion.ll:ptrLoadStoreTys`. 

Before the patch, we would only consider `<4 x i32>` as a candidate type
for vector promotion, and would find that it is a viable type for all
the slices.

After the patch, we now add `<2 x ptr>` as a candidate type due to slice
with user `store ptr %val0, ptr %obj, align 8` -- and flag that we
`HaveVecPtrTy`. The pre-existing behavior of this flag results in
removing the viable `<4 x i32>` and keeping only the unviable `<2 x
ptr>`, which results in a failure to promote.

The end result is failing to promote an alloca that was previously
promoted -- this does not appear to be the intent of that patch, which
has the goal of increasing promotions by providing more promotion
opportunities.

This PR preserves this behavior via a simple reorganization of the
implemention: try first the slice types with same size as the partition,
then, if there is no promotable type, try the `LoadStoreTys.`