[llvm-commits] [PATCH] SIV tests in LoopDependenceAnalysis

[Hal Finkel]

Sanjoy, thanks for the explanations. I think this looks alright; does
anyone else want to review?

 -Hal

On Sun, 4 Mar 2012 12:03:38 +0530
Sanjoy Das <sanjoy at playingwithpointers.com> wrote:

> Hi Hal!
> 
> Thanks for the comments.  I have removed the #include <iostream> and
> the const change (I had overlooked it in the earlier patches).
> 
> > What happens for nested loops?
> 
> For nested loops we check each subscript for dependence.  If we have
> independence in any one subscript, the entire access is independent.
> For instance:
> 
> for (i = 0 to n) {
>   a [5][i + 1] = a [4][i];
> }
> 
> There can never be a dependency since for no `i' is the tuple (5, i +
> 1) equal to the tuple (4, i).  This index by index comparison happens
> in LoopDependenceAnalysis::analysePair.
> 
> In an individual SIV test we check for only one pair of subscripts.
> So, analyzing the above example would involve analyzing the dependency
> between [5 and 4] and the dependency between [(i + 1) and i].
> 
> SIV analyzes pairs with a total of one induction variable between
> them, so it can analyze pairs like [5 and (i + 3)] and [(i + 2) and (2
> * i - 1)].  The snippet
> 
> const Loop *theLoop; // There is only one loop we're concerned about.
> {
>   DenseSet<const Loop*> loops;
>   getLoops(A, &loops);
>   getLoops(B, &loops);
>   assert(loops.size() == 1 && "Expected single loop in SIV test!");
>   theLoop = *loops.begin();
> }
> 
> finds this single loop (and hence single induction variable) in the
> two subscript expressions.
> 
> A more general case is an MIV subscript, where a subscript pair has a
> total of more than one loop induction variable.  This isn't
> implemented yet.
> 
> > Also, it might be a good idea to break up analyseSIV in to multiple
> > functions, one for each case being tested.
> 
> I refrained from doing this because it would involve passing around
> too much information and the resultant functions won't have any use
> anywhere else.
> 
> > Do you have any ideas about how to test this? Maybe that can wait
> > until something actually uses the analysis.
> 
> I think the current approach (the second patch) is okayish -- have opt
> dump information into stdout which FileCheck then compares.  I agree
> that once something actually uses LDA, we'll have better testing
> opportunities.
> 
> More importantly, I think a next good step would be calculate the
> direction of the loop-carried dependencies so that things like loop
> interchange can be implemented.
> 
> Thanks!
> --
> Sanjoy Das.
> http://playingwithpointers.com



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory