[PATCH] D19886: Add ability to use DependenceAnalysis from LoopAccessAnalysis

[silviu.baranga@arm.com via llvm-commits]

sbaranga added inline comments.

================
Comment at: lib/Analysis/LoopAccessAnalysis.cpp:1212
@@ +1211,3 @@
+        // (Src - Sink).
+        Dist = PSE.getSE()->getNegativeSCEV(Dist);
+      }
----------------
etherzhhb wrote:
> sbaranga wrote:
> > etherzhhb wrote:
> > > In order to address @sbaranga's comment, perhaps we can rewrite Dist with SCEVPredicateRewriter using the existing Predicate from PSE to incorporate the existing runtime checks.  
> > Yes, something like that can be used to keep the existing features of the LAA dependece analysis, but it wouldn't help if we wanted to refactor and replace this logic entirely with DependenceAnalysis.
> > 
> > What are we getting by using the Dep->getDistance? It might be better to just keep the old distance calculation (which should be equivalent and avoid additional SCEV rewritting).
> > 
> If DependenceAnalysis (and later the analysis from Polly, see one of this year's GSoC mentored by @jdoerfert) provide more precise result, and we can rewirte the SCEV returned by DependenceAnalysis with the predicates introduced by LoopAccessAnalysis to provide even more precise results, we may have some gain here.
> 
> 
That should be fine in the long run (and looks like it will have to be touched in the GSoC work), my only concern was that it might not make sense to do this it in the current change if it doesn't bring any gain (it would be over-engineering?).

Anyway, if we do want to use the distance returned by the DependenceAnalysis, we would have to do two things:

  - we would need to record this distance in the dependences produced by LLA, since other passes consume this (see isDependenceDistanceOfOne in LLE) and are currently assuming that the distance is computed by subtracting the SCEVs. There might be other examples that I'm not aware of.

  - add the boilerplate to PSE to version the SCEV directly (should be simple).

It would also be really nice if we could figure out a good (and common) interface for the dependence result (which would be part of the refactoring goal anyway).



http://reviews.llvm.org/D19886