> 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>
Hi Adam,
From: Adam Nemet [mailto:anemet at apple.com]
Sent: Wednesday, March 11, 2015 10:48 AM
To: Nema, Ashutosh
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] RFC: Loop versioning for LICM
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.
Please let me know if you have any questions.
I have gone through current LAA, found few gaps for reusing it.
i.e.
928 void LoopAccessInfo::analyzeLoop(const ValueToValueMap &Strides) {
1029 if (isUniform(Ptr)) {
1030 emitAnalysis(
1031 LoopAccessReport(ST)
1032 << "write to a loop invariant address could not be
vectorized");
1033 DEBUG(dbgs() << "LAA: We don't allow storing to
uniform addresses\n");
1034 CanVecMem = false;
1035 return;
1036 }
LAA is ignoring the cases where store is loop invariant, it sets memory can’t be
vectorize.
In loop versioning for LICM, we are more interested in loop invariant cases.
Invariant store is one of the important case for
“LICM::promoteLoopAccessesToScalars”
If there any loop invariant exists then only we do loop versioning.
This check looks specific to loop vectorizer, with this check we can’t use LAA
for LICM loop versioning.
If we like to make this reusable probably we need to remove this or make it
conditional.
Probably, agents to LAA can implements such check instead LAA.
Regards,
Ashutosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150317/0fe94c15/attachment.html>
Hi Ashutosh,> On Mar 16, 2015, at 9:06 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > > Hi Adam, > > From: Adam Nemet [mailto:anemet at apple.com <mailto:anemet at apple.com>] > Sent: Wednesday, March 11, 2015 10:48 AM > To: Nema, Ashutosh > Cc: llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] RFC: Loop versioning for LICM > > 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. > > I have gone through current LAA, found few gaps for reusing it. > > i.e. > 928 void LoopAccessInfo::analyzeLoop(const ValueToValueMap &Strides) { > 1029 if (isUniform(Ptr)) { > 1030 emitAnalysis( > 1031 LoopAccessReport(ST) > 1032 << "write to a loop invariant address could not be vectorized"); > 1033 DEBUG(dbgs() << "LAA: We don't allow storing to uniform addresses\n"); > 1034 CanVecMem = false; > 1035 return; > 1036 } > > LAA is ignoring the cases where store is loop invariant, it sets memory can’t be vectorize. > > In loop versioning for LICM, we are more interested in loop invariant cases. > Invariant store is one of the important case for “LICM::promoteLoopAccessesToScalars” > If there any loop invariant exists then only we do loop versioning. > > This check looks specific to loop vectorizer, with this check we can’t use LAA for LICM loop versioning. > If we like to make this reusable probably we need to remove this or make it conditional. > > Probably, agents to LAA can implements such check instead LAA.Not really. Don’t you need memchecks for loop-invariant addresses as well? I think we should just teach the analysis to also emit run-time checks for loop-invariant addresses. Assuming the memchecks pass we should have valid dependence analysis results so we could for example distribute the loop. We couldn’t vectorize thus the analysis should provide a new piece of information about the loop having accesses to loop-invariant addresses. Adam> Regards, > Ashutosh-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150319/23f29f81/attachment.html>