[llvm] [DependenceAnalysis] Extending SIV to handle separate loops (PR #128782)

[Alireza Torabian via llvm-commits]

1997alireza wrote:

> Effectively, with SeparateLoops=true, this will handle loops as if they are fused.
> 
> But it also means that the result is plain wrong for non-fused loops. E.g. the dependence distance `d` computed by e.g. `strongSIVtest` may result in `d > 0`, where in reality all the instances of write occur before the read because their loops are sequential, not nested.

Good point! To avoid the confusion among the original distances or directions and the new information we provide by this patch, now I will provide them in a different array. I added a new array of `DVEntry` named `DVSeparate` to include the `DVEntry` for separate levels and keep the `DV` array unchanged.

> Another concern is that the analysis makes the decision on how to loop fusion occurs. The FuseLoops pass may want to fust loops with non-equal trip count, then it has to make the decision which iterations are executed with which ones. Even in cases where the trip count matches such as
> 
> ```
> for (int i = 0; i < n; +=1)
>   A[i+1] += 1;
> for (int i = 0; i < n; +=1)
>   A[i] += 2;
> ```
> 
> loop fusion would optimally be
> 
> ```
> for (int i = 0; i < n+1; +=1) {
>   if (i > 0) A[i] += 1;
>   if (i < n) A[i] += 2;
> }
> ```
> 
> or after LoopBoundSplitPass etc.
> 
> ```
> A[0] += 2;
> for (int i = 0; i < n+1; +=1) 
>   A[i] += 3;
> A[n] +=  1;
> ```
> 
> i.e. not as naive as DA would assume. Ideally, we would chose an approach that allows us to extend FuseLoops over time.

Loop fusion or or any other optimization passes that want to use the analysis results can decide how to use it. For the case you mentioned, loop fusion can peel the iterations first to make the trip counts the same and then apply DA.

> I think instead of a `SeparateLoops` parameter, DA should receive the info which loops are considered to be fused from FuseLoops -- otherwise they might be disagree. "SeparateLoops" isn't a good name anyway. It goes pack to the old problem that we want to analyze the result of a optimization without the optimization having been applied first. It would be great if we could leave pass-specific concerns out of DA itself, it does not scale well with the number of passes, but I concede that sometimes it might be a pragmatic solution.

We prefer the DA to provide information across two loops, enabling loop fusion to identify dependencies before applying the optimization.



https://github.com/llvm/llvm-project/pull/128782