[PATCH] D76132: [LoopUnrollAndJam] Changed safety checks to consider more than 2-levels loop nest.

[Bardia Mahjour via Phabricator via llvm-commits]

bmahjour added a comment.

In D76132#1947897 <https://reviews.llvm.org/D76132#1947897>, @Meinersbur wrote:

> In D76132#1947821 <https://reviews.llvm.org/D76132#1947821>, @Whitney wrote:
>
> > I am still confused. Your version only allow GT (by checking == GT). My version only allow GT, LT, NE (by checking ! &EQ). So both versions requires us to check further with GE.
> >  I was trying to use
> >
> >   for i
> >     for j        <= unroll loop
> >       for k
> >          S1: A[i][j][k]
> >          S2: A[i-1][j+1][k-1]
> >
> >
> > as an example, where your version would consider as unsafe and my version would consider as safe.
> >  Am I correct to think loop-j is safe to unroll and jam?
>
>
> Yes
>
> > If yes, do you have an example where LT or NE for loop-i should be considered as unsafe for unroll and jam loop-j?
>
> My justification, as laid out in the comments, is that a GT dependency ensures that the dependency vector is lexicographic positive. An LT or NE dependency does not do that. I would need to see an argument -- not an example -- why LT or NE provide safety. Also consider that DependencyInfo can overapproximate direction bits, so there may not be an example with exactly these direction vectors.


I believe Whitney's reasoning is based on the assumption that if outer levels (levels enclosing the loop being unroll-and-jammed) have a non-equal direction, then the locations accessed in the inner levels cannot overlap in memory. One counter example to that I can think of is where the indexes overlap into neighboring dimensions. @Meinersbur I'm just curious, is that what you had in mind too? I agree we need to be conservative, but I just want to know the concern so we can document/think about it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76132/new/

https://reviews.llvm.org/D76132