[PATCH] [Patch] Loop Interchange Pass

[hfinkel at anl.gov]

================
Comment at: lib/Transforms/Scalar/LoopInterchange.cpp:415
@@ +414,3 @@
+  // We currently handle only 1 induction variable inside the loop. We also do
+  // not handle reductions as of now.
+  for (auto I = innerLoopHeader->begin(), E = innerLoopHeader->end(); I != E;
----------------
karthikthecool wrote:
> hfinkel wrote:
> > karthikthecool wrote:
> > > hfinkel wrote:
> > > > How are you checking for reductions here? Do you need to check that the one PHI you've found is not used outside of the loop?
> > > We are currently checking if there is only 1 PHI node in the lop header which will corrospond to the induction variable. If we find any other PHI's either due to reductions or triangular loop structure. We currently exit as  current limiation.
> > No, I mean uses outside of the loops in general. I don't think you check for that. You check for:
> > 
> >   if (numUsageinLatch + numUsageinHeader != 1)
> >     return false;
> > 
> > but the PHI could be used in any block dominated by the loop. Do you need to check for that?
> > 
> >   int i, j;
> >   for (int i = 0; i < n; ++i)
> >     for (int j = 0; j < m; ++j)
> >       a[i][j] = 7;
> > 
> >   cout << "final i, j = " << i << ",  " << j << "\n";
> > 
> Hi Hal,
> The way i was handling this was-
> since the loops were tightly coupled we were getting the lcssa phi for these loops in the outer loop latch which i was splitting and moving outside loop.  I was able to get the correct value for i and j in this case.
> 
> But i think i can add check to avoid these cases as well. Since we do not want uses outside loop is it ok to have a check like-
>   if (isa<PHINode>(InnerLoopLatch->begin()))
>     return false;
>   if (isa<PHINode>(OuterLoopLatch->begin()))
>     return false;
> This will make sure we do not have any outside uses defined inside the loop. Does this check look good. Will this make this transform too restrictive? 
> Thanks for answering my silly queries i'm still getting hold of loop optimizations.
> Regards
> Karthik Bhat
Ah, you're right. I think that, given our current restrictions, the final values outside the loop nest will always be the same, so this is fine. (we should have a regression test showing that we still can interchange in this case).

http://reviews.llvm.org/D7499

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/