[LLVMdev] RFC: Loop versioning for LICM

[Adam Nemet]

> On Mar 5, 2015, at 10:33 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote:
> 
>  
> I am about to post the patches to make LAA suitable for Loop Distribution.  As you will hopefully find this will make the LAA more generic.  I will cc you on the patches.
>  
> Sure Adam.
>  
> RuntimeCheckEmitter
> “RuntimeCheckEmitter::addRuntimeCheck”
> While creating runtime check I have found, some of the things are not getting considered.
> 1) No need to check if two read only pointers intersect.
> 2) Only need to check pointers between two different dependency sets.
> 3) Only need to check pointers in the same alias set
>  
> I’m sure if we like this to be used by other optimization then not all optimization appreciate
> above checks. Specifically LoopVersioning does not care about this, it expects all the pointers
> in a loop should be considered for a memory check. Also it does not care about different
> dependency set & different alias sets.
>  
> I suggest we can make these checks optional, and give flexibility to users of this class to set it.
>  
> I am not sure I follow.  The logic is meant to reduce the number of memory checks necessary to ensure the independence of may-alias accesses.  We can omit 1-3 but then we would end up with unnecessary checks that could unnecessarily slow things down.
>  
>  
> I just wanted to keep a flexibility open.
> We can give a try to LoopVersioning by keeping point 1 & 3 checks. but I’m not sure about point 2.
> Will give a try to your upcoming patch.
>  
>  
>  
> LoopAccessAnalysis::analyzeLoop
> Here again its very specific to LoopVectorizer. 
> The way it handles stores & loads may not be appreciated by other optimization
> expecting other treatment. I suggest we should think on flexibility for user to
> override load & store handling. We can provide virtual methods for load & store
> handling (i.e. analyzeLoads & analyzeStores). Also some of the optimization may not
> like call instruction, or further they like to analyze call. We should also think on those
> lines to make some provision.
>  
> Can you please elaborate how you want to analyze function calls?
> For calls expecting overridable method, providing flexibility to user to redefine behavior.
> There are few possible cases:
> may not like any call in the loop body, or may like only few specific calls.
> or may not like to pass any pointer/address out of loop by calls.
>  
> AccessAnalysis & LoopAccessAnalysis are tied up dependency check, If some analysis
> needs same functionality except dependency check then there should be provision available.
> i.e. LoopVersioning needs similar stuff except dependency analysis, for now possibility is
> extend & rewrite functions by removing dependency checks. 
>  
> I actually consider the coupling of dependency analysis and memcheck generation as a feature.  Since dependence analysis can further disambiguate memory accesses (as in the DependencySet except you mentioned above) it can reduce the number of run-time memory checks necessary.
> As mentioned above I’m not sure this will be useful for loopVersioning.
> But like to give a try with your upcoming patch.

Hi Ashutosh,

My changes are committed now.  LoopAccessAnalysis is an analysis pass, so it has the advantage that the result of the analysis is cached until it gets invalidated (i.e. when the loop changes).

For an example of how to use it, you can look at either the loop-vectorizer in the tree or the WIP patch for the loop-distribution pass in http://reviews.llvm.org/D6930 <http://reviews.llvm.org/D6930>.

Please let me know if you have any questions.

Adam

>  
> 
> Thanks,
> Ashutosh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150310/6f81764f/attachment.html>