[PATCH] D128073: [SROA] Try harder to find a vector promotion viable type when rewriting

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 5 19:28:22 PDT 2022


arsenm accepted this revision.
arsenm added a comment.
This revision is now accepted and ready to land.

LGTM



================
Comment at: llvm/test/Transforms/SROA/sroa-common-type-fail-promotion.ll:338-342
+; CHECK-NEXT:    [[B_BLOCKWISE_COPY_SROA_0:%.*]] = alloca float, align 16
+; CHECK-NEXT:    [[B_BLOCKWISE_COPY_SROA_4:%.*]] = alloca float, align 4
+; CHECK-NEXT:    [[B_BLOCKWISE_COPY_SROA_7:%.*]] = alloca float, align 8
+; CHECK-NEXT:    [[B_BLOCKWISE_COPY_SROA_10:%.*]] = alloca float, align 4
+; CHECK-NEXT:    [[B_BLOCKWISE_COPY_SROA_13:%.*]] = alloca <8 x half>, align 16
----------------
vangthao wrote:
> arsenm wrote:
> > I'm not seeing why these allocas were not eliminated
> My change only works if there is a common type found and that common type happens to be a vectortype. In the other tests the common vectortype was found from a `store <4 x float> ...` instruction. If we remove such instruction then there is no common vectortype and my changes to look at the original allocated type and vector promotion check is not enabled.
> 
> From what I have observed, SROA fails to promote these allocas because it found common slicety of float while there are load halfs. This causes some offset issues and failure to promote when `visitLoadInst()` is called. If we change float type to half type by adjusting the stores to also be half type then we would have no issue promoting the allocas.
Can you look into handling these cases in a follow on patch?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128073/new/

https://reviews.llvm.org/D128073



More information about the llvm-commits mailing list