[llvm] [DA] Add tests for nsw doesn't hold on entier iteration (PR #162281)

[Ehsan Amiri via llvm-commits]

amehsan wrote:

> > It is not clear to me where we make this assumption and what are the consequences of that. But before discussing that I have another question: I believe you are talking about this example from your testcase:
> > ```
> > ; for (i = 0; i < INT64_MAX - 1; i++)
> > ;   if (i < 1000)
> > ;     for (j = 0; j < 2000; j++)
> > ;       a[i + j] = 0;
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > and you are saying for DA to be correct we need to check that a loop guard exists (or may be check what the loop guard is) and bail out. Now I can change your example to the following:
> > ```
> > for (i = 0; i < INT64_MAX - 1; i++)
> >    if (i < 1000) {
> >      for (k = 0;  k < 5000; k++) {
> >            // do something in the loop
> >       }
> >      // some complex code possibly involving control flow 
> >      for (j = 0; j < 2000; j++)   
> >        a[i + j] = 0;
> >      }
> >   } // if (i < 1000)
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Your comment is applicable to this example as well. Here `j` loop has no guard. How do you want to handle this case? Checking the guard doesn't seem to work here. Also please answer the same question about the following example
> > ```
> > for (i = 0; i < INT64_MAX - 1; i++)
> >    
> >      for (k = 0;  k < 5000; k++) {
> >            if (i > 1000) goto X; // X is a label outside the loopnest.
> >       }
> >      // some complex code possibly involving control flow 
> >      for (j = 0; j < 2000; j++)   
> >        a[i + j] = 0;
> >      }
> >   } 
> > ```
> 
> I think we can ensure it by checking the (post-)dominance for headers and/or latches between the outer loop and the inner loop. It might also be worth noting that `ScalarEvolution::LoopGuards` already implements the function that collects the conditions required to enter the loop.

We need something like this. However there are some subtleties to consider. Dominance directly does not work, because the inner loop might be `for (int i = 0; i < n; i++)` and then for `n = 0` the inner loop is not executed (Unless the loop guard is hoisted by loop unswitch). We need to make sure the case of early exit is also considered.

But before getting into details of this, I believe we need to think about a couple of higher level issues:

(1) I wonder if there is a proof of correctness of these tests in the literature that we can look into and figure out what are the assumptions for each one? It is much better if we can gather this issues in a systematic way. If not, it might be even better to try to write down the proofs and in the process we can find what do we need to assume. That is easier than discovering this bugs one by one.

(2) Different tests might have different assumptions. We need to be careful about this. One way to handle this, could be to require loops to be in a more strict canonical form, before applying any loop optimizations. However, this will be large amount of work and at this point I don't know whether we have a justification for it or not. But if this is something that we are going to be forced to do down the road, may be we need to pause now and think about it.

I believe our best next step, would be to start gathering the list of assumptions required for each of the tests. (Unless we have a reason that missing assumption are very rare and it is not something to generally worry about).

One last thing is that I still haven't done a careful debug of the example provided. I assume you have done this and there is no other issue (such as overflow in calculation, or other problems in DA computations)

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