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

Hongbin Zheng via llvm-commits llvm-commits at lists.llvm.org
Thu May 5 10:38:59 PDT 2016


etherzhhb added a subscriber: jdoerfert.

================
Comment at: lib/Analysis/LoopAccessAnalysis.cpp:1194
@@ +1193,3 @@
+      DEBUG(dbgs() << "LAA: DA returned no dependence!\n");
+      return Dependence::NoDep;
+    }
----------------
sbaranga wrote:
> DA is independent of the loop versioning. Therefore if we have NoDep here then the versioning performed by replaceSymbolicStrideSCEV/isStridedPtr wouldn't help. So by moving this above the replaceSymbolicStrideSCEV calls, we could reduce the number of run-time checks needed.
> 
Yes, we can call DA early to get the distance SCEV early and avoid the later replaceSymbolicStrideSCEV.

If the result provided by DA is more precise, it is also useful in this stage. See below.

================
Comment at: lib/Analysis/LoopAccessAnalysis.cpp:1212
@@ +1211,3 @@
+        // (Src - Sink).
+        Dist = PSE.getSE()->getNegativeSCEV(Dist);
+      }
----------------
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.




http://reviews.llvm.org/D19886





More information about the llvm-commits mailing list