[PATCH] D20789: Consecutive memory access in Loop Vectorizer - fixed and simplified

[Dorit Nuzman via llvm-commits]

dorit added a subscriber: dorit.
dorit added a comment.

In https://reviews.llvm.org/D20789#502014, @sbaranga wrote:

>


...

> Is that function inlined? Otherwise, the two pointers have different underlying objects. For accesses with different underlying objects, we guarantee no dependence using either alias analysis or a runtime no alias check.

> 

> This is done in AccessAnalysis::canCheckPtrAtRT (and implicitly in AccessAnalysis::processMemAccesses).


I have a question about this (unrelated to Elena's patch; sorry to digress a little):

Looks like for the pointers that we can't anti-alias we call canCheckPtrAtRT with ShouldCheckWrap=false :

  // Find pointers with computable bounds. We are going to use this information
  // to place a runtime bound check.
  bool CanDoRTIfNeeded = Accesses.canCheckPtrAtRT(*PtrRtChecking, PSE->getSE(),
                                                  TheLoop, SymbolicStrides);

And if there is any unknown dependence distance we call canCheckPtrAtRT with ShouldCheckWrap=true:

  if (!CanVecMem && DepChecker->shouldRetryWithRuntimeCheck()) {
      DEBUG(dbgs() << "LAA: Retrying with memory checks\n");
      …
      CanDoRTIfNeeded = Accesses.canCheckPtrAtRT(*PtrRtChecking, SE, TheLoop,
                                                 SymbolicStrides, true);

Both cases will end up generating similar runtime pointer-range comparison… why are we not concerned with wrapping in the first?

And when ShouldCheckWrap is true: I assume the unit stride restriction in isNoWrap comes from the concern not to refer to an address beyond the location of the first element past the array boundary? Is that because we compute the pointer range as "ptr+Stride*TripCount", which might refer to "Stride" locations past the array boundary (and therefore may wrap around the address space)?

thanks!
Dorit


Repository:
  rL LLVM

https://reviews.llvm.org/D20789