[PATCH] D115356: [LV] Remove what seems like stale code in collectElementTypesForWidening.

[Sander de Smalen via Phabricator via llvm-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG95a93722db2d: [LV] Remove what seems like stale code in collectElementTypesForWidening. (authored by sdesmalen).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115356

Files:
  llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
  llvm/test/Transforms/LoopVectorize/X86/vector_ptr_load_store.ll


Index: llvm/test/Transforms/LoopVectorize/X86/vector_ptr_load_store.ll
===================================================================
--- llvm/test/Transforms/LoopVectorize/X86/vector_ptr_load_store.ll
+++ llvm/test/Transforms/LoopVectorize/X86/vector_ptr_load_store.ll
@@ -52,7 +52,7 @@
 ;       p[i][y] = (int*) (1 + q[i]);
 ;     }
 ; CHECK: test_nonconsecutive_store
-; CHECK: LV: The Smallest and Widest types: 16 / 16 bits.
+; CHECK: LV: The Smallest and Widest types: 16 / 64 bits.
 ; CHECK: LV: Selecting VF: 1
 define void @test_nonconsecutive_store() nounwind ssp uwtable {
   br label %1
@@ -120,7 +120,7 @@
 
 ;; However, we should not take unconsecutive loads of pointers into account.
 ; CHECK: test_nonconsecutive_ptr_load
-; CHECK: LV: The Smallest and Widest types: 16 / 16 bits.
+; CHECK: LV: The Smallest and Widest types: 16 / 64 bits.
 ; CHECK: LV: Selecting VF: 1
 define void @test_nonconsecutive_ptr_load() nounwind ssp uwtable {
   br label %1
Index: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
===================================================================
--- llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
+++ llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
@@ -5990,17 +5990,7 @@
       if (auto *ST = dyn_cast<StoreInst>(&I))
         T = ST->getValueOperand()->getType();
 
-      // Ignore loaded pointer types and stored pointer types that are not
-      // vectorizable.
-      //
-      // FIXME: The check here attempts to predict whether a load or store will
-      //        be vectorized. We only know this for certain after a VF has
-      //        been selected. Here, we assume that if an access can be
-      //        vectorized, it will be. We should also look at extending this
-      //        optimization to non-pointer types.
-      //
-      if (T->isPointerTy() && !isConsecutiveLoadOrStore(&I) &&
-          !isAccessInterleaved(&I) && !isLegalGatherOrScatter(&I))
+      if (!T->isSized())
         continue;
 
       ElementTypesInLoop.insert(T);


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D115356.397522.patch
Type: text/x-patch
Size: 2018 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220105/71b76f2c/attachment.bin>