[PATCH] D113554: Delete code comments for impossible bugs

[Liren.Peng via Phabricator via llvm-commits]

Peakulorain created this revision.
Peakulorain added a reviewer: reames.
Herald added subscribers: javed.absar, hiraditya.
Peakulorain requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Since Step from AddRec which analyzed from GEP is SCEVConstant,
and Step is not Zero also, the GEP for load/storage will not be
a narrow GEP in inferring loop bound from array access.


https://reviews.llvm.org/D113554

Files:
  llvm/lib/Analysis/ScalarEvolution.cpp


Index: llvm/lib/Analysis/ScalarEvolution.cpp
===================================================================
--- llvm/lib/Analysis/ScalarEvolution.cpp
+++ llvm/lib/Analysis/ScalarEvolution.cpp
@@ -7338,7 +7338,6 @@
 
       // Memory operation pattern which have gaps.
       // Or repeat memory opreation.
-      // And index of GEP wraps arround.
       if (Step->getAPInt().getActiveBits() > 32 ||
           Step->getAPInt().getZExtValue() !=
               ElemSize->getAPInt().getZExtValue() ||
@@ -7362,10 +7361,6 @@
       if (Ty->getElementType() != GEPT->getElementType())
         continue;
 
-      // FIXME: Since gep indices are silently zext to the indexing type,
-      // we will have a narrow gep index which wraps around rather than
-      // increasing strictly, we shoule ensure that step is increasing
-      // strictly by the loop iteration.
       // Now we can infer a max execution time by MemLength/StepLength.
       const SCEV *MemSize =
           getConstant(Step->getType(), DL.getTypeAllocSize(Ty));


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D113554.386106.patch
Type: text/x-patch
Size: 1038 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20211110/4f383127/attachment.bin>