[LLVMdev] RFC: Loop versioning for LICM

[Adam Nemet]

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>