[LLVMdev] RFC: Loop versioning for LICM

Nema, Ashutosh Ashutosh.Nema at amd.com
Thu Mar 5 22:33:32 PST 2015

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.

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.

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.


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

More information about the llvm-dev mailing list