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

[sdesmalen]

Summary

This was originally added in rG22174f5d5af1eb15b376c6d49e7925cbb7cca6be
although that patch doesn't really mention any reasons for ignoring the
pointer type in this calculation if the memory access isn't consecutive.

[sdesmalen]

Gentle ping

[david-arm]

LGTM. I don't see why we should be treating stores/loads involving 64-bit pointers any different to normal 64-bit values. Furthermore, there are no existing tests defending the case where VF>1, which suggests the removed code has little value. If we have an accurate cost model that reflects the cost of scalarising gathers/scatters then that should ensure a sensible choice of interleave count.

[nikic]

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp

5993

Can this be an assertion? The load/store type can't be unsized, and I assume a reduction type can't be unsized either?

[sdesmalen]

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp

5993

It can, thanks for the suggestion. Are you happy with me pushing this change directly?

[nikic]

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp

5993

Sure.

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp

for (Instruction &I : BB->instructionsWithoutDebug()) {
           continue;
         T = RdxDesc.getRecurrenceType();
       }
 
       // Examine the stored values.
       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);
     }
   }
 }
 
 unsigned LoopVectorizationCostModel::selectInterleaveCount(ElementCount VF,

llvm/test/Transforms/LoopVectorize/X86/vector_ptr_load_store.ll

 ; therefore the widest type should be i16.
 ; int* p[2048][8];
 ; short q[2048];
 ;   for (int y = 0; y < 8; ++y)
 ;     for (int i = 0; i < 1024; ++i) {
 ;       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
 
 ; <label>:1                                       ; preds = %14, %0
   %2 = phi i64 [ 0, %0 ], [ %15, %14 ]
   br label %3
 

 
 ; <label>:12                                      ; preds = %1
   %13 = phi i8 [ %9, %1 ]
   ret i8 %13
 }
 
 ;; 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
 
 ; <label>:1                                       ; preds = %13, %0
   %2 = phi i64 [ 0, %0 ], [ %14, %13 ]
   br label %3