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

[Michael Kruse via Phabricator via llvm-commits]

Meinersbur added a comment.

In D76132#1949923 <https://reviews.llvm.org/D76132#1949923>, @bmahjour wrote:

> > S2(i2,j2,k2) depends on S1(i1,j1,k1) iff i1==i2-1(A[i1] and A[i2-1] access the same element), j1==j2+1, k1==k2-1 and (i1,j1,k1) <=_{lexicographic} (i2,j2,k2), 
> >  in other words, the dependence vector is (+1,-1,+1) or (GT,LT,GT) [direction from S1->S2, since S1 is the source and S2 is the consumer].
>
> This is a bit counter intuitive, but a positive dependence direction, is represented as LT (not GT). See section 4.2.1 in //G.G, Ken Kennedy, C.W. Tseng, 1990. Practical Dependence Testing.//
>  The corresponding direction vector for (+1,-1,+1) is (LT, GT, LT) which would be a lexicographically positive direction vector.


I indeed seem to have been confused the directions, maybe influence by the original implementation predominantly testing against `GT`. Thanks for pointing this out. It also means that some assumptions I had while writing the code were wrong.

One other is that DependenceAnalysis would not return a `[> ...]` dependence, as this would be a dependence of Dst to a Src in the future. Well:

  for (int i = 0; i < n; ++i) {
          A[i] = 42;
          sum += A[i+1];
  }

  $ opt -da
  Src:  store double 4.200000e+01, double* %arrayidx, align 8 --> Dst:  %0 = load double, double* %arrayidx2, align 8
    da analyze - consistent flow [>]!

It's not a flow dependence, but an anti-dependence. This the result of DA being invoked as `analyze(store,load)`, but DA is not able to determine from the direction whether it's a flow or an anti-dependence.

That is, one DA call returns two results mixed into a single dependence vector: Src --> Dst and Dst --> Src. That doesn't look ideal and I am not sure about the consequences.

In D76132#1949936 <https://reviews.llvm.org/D76132#1949936>, @bmahjour wrote:

> 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.


Could this be commented, with a bit more detail, in the source code?

> 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.

What I had in mind was if DependencyInfo was combining multiple cases into a single `Dependence` result. For instance, depending on a condition `c` the dependence vector is either (+1,-1) or (0,+1). The combined direction flags would be (<=,<>). On the other side, if a particular instance has a reverse (i.e. negative, `>`, GT) direction, then one previous dimensions must have been positive (otherwise the value would have time-traveled). That could also serve a a justification.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76132