[LLVMdev] RFC: Loop versioning for LICM

[Nema, Ashutosh]

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>