This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by anemet on Mar 6 2015, 10:22 AM.

Details

Summary

LoopDistribution needs to query various results of the dependence
analysis. This series will expose some more APIs and state of the
dependence checker.

This patch is a simple one to just expose the DepChecker instance. The
set is compile-time neutral measured with LTO bitcode files of
SpecINT2006. Also there is no assembly change on the testsuite.

Diff Detail

Event Timeline

anemet updated this revision to Diff 21372.Mar 6 2015, 10:22 AM
anemet retitled this revision from to [LoopAccesses 1/3] Expose MemoryDepChecker to LAA users.
anemet updated this object.
anemet edited the test plan for this revision. (Show Details)
anemet added reviewers: hfinkel, aschwaighofer, nadav.
anemet added a subscriber: Unknown Object (MLST).
hfinkel accepted this revision.Mar 7 2015, 10:35 PM
hfinkel edited edge metadata.

LGTM.

This revision is now accepted and ready to land.Mar 7 2015, 10:36 PM
hfinkel added inline comments.Mar 7 2015, 10:45 PM
include/llvm/Analysis/LoopAccessAnalysis.h
94

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).

anemet added inline comments.Mar 9 2015, 3:56 PM
include/llvm/Analysis/LoopAccessAnalysis.h
94

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?

hfinkel added inline comments.Mar 9 2015, 4:20 PM
include/llvm/Analysis/LoopAccessAnalysis.h
94

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).

anemet added inline comments.Mar 9 2015, 4:58 PM
include/llvm/Analysis/LoopAccessAnalysis.h
94

OK, I certainly agree that it does sound like a precondition and that is a bit strong.

On the other hand, if we were to rely on isDepedent to answer these queries we would trigger the whole ShouldRetryWithRuntimeCheck path which completely disregards DependencySets. So we could end up with more memchecks in order the vectorize the loop.

So it's probably better to think of it as a precondition not for correctness but for the proper division of work between MemoryDepChecker and AccessAnalysis/RuntimePointerCheck.

This is probably a bit too subtle to capture in the class comment though... Perhaps something like:

"(We handle may-aliasing accessed using different underlying pointers in AccessAnalysis/RuntimePointerCheck by emitting memchecks.)"

hfinkel added inline comments.Mar 9 2015, 5:17 PM
include/llvm/Analysis/LoopAccessAnalysis.h
94

Why don't we just say this:

// Note: This class will compute a conservative dependence for access to different underlying pointers. Clients, such as the loop vectorizer, will sometimes deal these potential dependencies by emitting runtime checks.
anemet added inline comments.Mar 9 2015, 5:21 PM
include/llvm/Analysis/LoopAccessAnalysis.h
94

Works for me!

anemet closed this revision.Mar 10 2015, 10:46 AM

r231805

Thanks very much for your reviews, Hal!