[PATCH] [LoopAccesses 1/3] Expose MemoryDepChecker to LAA users

[hfinkel at anl.gov]

================
Comment at: include/llvm/Analysis/LoopAccessAnalysis.h:94
@@ +93,3 @@
+/// This class works under the assumption that we already checked that memory
+/// locations with different underlying pointers are "must-not alias".
+/// We use the ScalarEvolution framework to symbolically evalutate access
----------------
anemet wrote:
> hfinkel wrote:
> > Also, IIRC, this assumption about underlying pointers not aliasing is not quite true (especially after I introduced the alias-set-tracker-based access partitioning), but we should return an 'Unknown' dependence given pointers with different (potentially aliasing) underlying pointers. We should probably remove this statement (unless you feel it is still true).
> Could you please elaborate why you think it's not true?  I thought it was true assuming we passed the run-time checks.
> 
> My understanding is that we partition the accesses first along the different alias sets and then along the different underlying pointers used.  Then we perform dependence checking within the partitions (each sharing the same alias set and underlying pointer).  I am not sure how we could see accesses with different underlying pointers in isDependent.
> 
> For accesses in the same alias set but using a different underlying pointer we emit a run-time check (same AliasSetId, different DependencySetId).
> 
> Am I missing something?
> My understanding is that we partition the accesses first along the different alias sets and then along the different underlying pointers used.

We do, but my point is that I don't see what in this class assumes, or depends on the fact, that we've done that. If we ask for the dependence of two pointers with different underlying values, then we should hit this code:

  const SCEVConstant *C = dyn_cast<SCEVConstant>(Dist);
  if (!C) {
    DEBUG(dbgs() << "LAA: Dependence because of non-constant distance\n");
    ShouldRetryWithRuntimeCheck = true;
    return true;
  }

in isDependent. If this is not a pre-condition to using the class, then we should remove or rephrase this comment (because it sounds like a precondition).

http://reviews.llvm.org/D8113

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/