diff options
| author | Jeffrey Byrnes <jeffrey.byrnes@amd.com> | 2024-01-23 17:22:49 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-01-23 17:22:49 -0800 |
| commit | f709fbb1bb5e6240aad4edeb2f0e417df74cfa27 (patch) | |
| tree | 7d2392a56970fc3c3ef350840224daeb8a37edb0 /llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp | |
| parent | c51ab483e6c2d991a01179584705b83fbea1940d (diff) | |
| download | llvm-f709fbb1bb5e6240aad4edeb2f0e417df74cfa27.zip llvm-f709fbb1bb5e6240aad4edeb2f0e417df74cfa27.tar.gz llvm-f709fbb1bb5e6240aad4edeb2f0e417df74cfa27.tar.bz2 | |
[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.`
Diffstat (limited to 'llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp')
0 files changed, 0 insertions, 0 deletions
