[llvm-commits] [PATCH] SIV tests in LoopDependenceAnalysis
Hal Finkel
hfinkel at anl.gov
Mon Mar 12 23:02:24 PDT 2012
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
More information about the llvm-commits
mailing list