[PATCH] D143225: [SROA] Create additional vector type candidates based on store and load slices
Han Zhu via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Feb 14 15:40:36 PST 2023
zhuhan0 added inline comments.
================
Comment at: llvm/test/Transforms/SROA/sroa-common-type-fail-promotion.ll:26
+; CHECK-NEXT: [[B_BLOCKWISE_COPY_SROA_0_4_VEC_EXTRACT:%.*]] = extractelement <8 x i16> [[TMP0]], i32 2
+; CHECK-NEXT: [[TMP3:%.*]] = bitcast i16 [[B_BLOCKWISE_COPY_SROA_0_4_VEC_EXTRACT]] to half
; CHECK-NEXT: ret void
----------------
vangthao wrote:
> There seems to be a regression here.
Hi, this is actually the result of a bug fix that we happened to put in in this diff (line 2001 - 2028 in the new version), not related with the optimization change. There was a bug where `RankVectorTypes` which is not an equivalence relation but used in `std::unique`. And when a non-equivalence relation is used, the behavior is undefined. Take `test_zeroinit` as an example, there are two candidates <4 x i32> and <8 x i16> during `isVectorPromotionViable`. But due to this bug, <8 x i16> was removed by `CandidateTys.erase` and <4 x i32> is not viable so the transformation failed unexpectedly. I could separate the bug fix if that's better. On the other hand, I don't think this bitcast addition is going to show up in the end after backend lowering anyways.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D143225/new/
https://reviews.llvm.org/D143225
More information about the llvm-commits
mailing list