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

[Ryotaro Kasuga via llvm-commits]

kasuga-fj wrote:

> > I believe this issue will be fixed by checking the loop-guard and/or `nsw`/`nuw` properly.
> 
> Need to do more investigation. But checking the loop guard in DA is almost certainly incorrect. One evidence is that the following loop with no loop guard has the same problem
> 
> ```
> void foo2 (int *a ) {
> 
>   unsigned long long i;
>   unsigned long long j;
> 
>   for (i = 0; i < 9223372036854775806; i++) {
>     for (j = 0; j < 2147483640; j++) {
>       a[i + j * 4294967296] = 0;
>       a[j * 2] = 0;
>     }
>   }
> }
> ```
> 
> > Here, what I'm not confident about is, what happens when assuming the two loops (`%loop.j.0` and `%loop.j.1`) are fused in such cases?
> 
> It is a completely orthogonal issue. The root cause of this particular bug might be in SCEV or in DA (We are looking into it. Please wait). But anyways, not related to this patch.

(In the hope of saving your time)

It is known that DA has several issues (some of which you may find in GitHub issues), such as the following:

- The interpretations of signed and unsigned are mixed up.  
- It does not take AddRec wrapping into account.  
- Overflows occur during the analysis.[^note]  
  - The overflow I’m referring to here is not in the original program, but in the arithmetic operations inside DA.

These issues violate the assumptions of the underlying algorithm, which can lead to incorrect results. Your example `foo2` seems to be one such case (though I’m not exactly sure what happens where). I’m trying to address this problem in https://github.com/llvm/llvm-project/pull/154527 by proving that signed-wrap does not occur when `nsw` is attached to an AddRec. The example I raised (with a loop guard `if (i < 2147483640)`) is slightly different from yours, since the AddRec corresponding to `i + j * 4294967296` has the `nsw` flag. However, it turns out that checking this flag alone is not sufficient. I’m almost certain now that loop guards need to be checked *somewhere* in DA, regardless of whether the loops can be fused or not...

I apologize for my bad communication (the more I looked into DA, the more bugs I found, so I became overly nervous...). However, I found the discussion very meaningful, and I sincerely appreciate it. Thank you.

[^note]: Because of these circumstances, for example, overestimating backedge-taken count might seem conservative (at least theoretically), but in fact it could lead to incorrect outcomes in the current DA, I think.

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