[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