[llvm] [DA] runtime predicates for delinearization bounds checks (PR #170713)

[Sjoerd Meijer via llvm-commits]

sjoerdmeijer wrote:

> Just as a high-level question: Do we want to introduce more runtime predicates at this point in time? Given that there is a lot of active ongoing work on correctness issues in DA/Delinearization, it may be better to delay this until a later time, just to make it easier to do further code changes, without also having to maintain the predicates along the way.
> 
> I've been out for a while and am not up to date on the DA/Delinearization work, but IIRC these runtime predicates are not yet used anywhere, right? They only appear in the analysis output for now? I expect that actually making use of them will be quite challenging, because of the need to trade off the value of the transform with the probability of passing the runtime check and the code size increase of performing loop versioning. Having a lot of runtime checks implemented will probably make this harder than introducing them gradually and evaluating which of them are actually valuable in practice.
> 
> On the other hand, I could see value in doing this now if this helps with testing somehow, e.g. because it allows us to easily test situations in DA that would otherwise be hard to test because of delinearization failures. Is something like this the case?

Welcome back @nikic . :-)

I think the above is fair assessment of the situation. I would like to add a few things though.

First of all, there has a lot of discussions about two different approaches to deal with wrapping behaviour. This spans different tickets and many weeks, and it is difficult to catch up on. The following is my attempt to briefly summary the situation. @kasuga-fj found a problem with monotonicity as it is currently defined/implemented. At different program scopes, monotonicty may or may not hold due to conditions or loop guards. He is looking at defining "iteration domains" where monotonicity holds. Another school of thought pursued by @amehsan is saying that monotonicity is a special case of wrapping or the lack thereof, so monotonicity as concept may not be necessary if dependence test can be adapted to be accurate for these cases. Both are prototyping their approach, which then allows us to look at this and see what the way forward is.

Besides this, we also have the runtime predicates. The way I look at this as follows:
- this is mostly orthogonal to the work mentioned above, because when dependence tests can't prove (in)dependence, we can proceed dependence checks under these assumptions, so we can handle a larger class of applications. And for now, yes, it also allows us to continue the work when delinearization fails. 
- runtime predicates isn't a new concept, my understanding is that Polly also uses this. Maybe @Meinersbur can confirm and elaborate.
- The implementation to add runtime checks isn't very difficult, I doubt it will really get into the way of other things.

But I agree that we haven't shown how to use these runtime predicates when it comes to actually performing a transformation. What I propose is the following:
- I will create an IR reproducer of our proxy workload and motivating example and create a merge request to add this as a loop-interchange regression test,
- This allows us to see what is necessary to get it interchanged, what dependence checks are doing, and how transforming it could look like using runtime predicates.

So I will add the regression test first which I will do early this week, and after that start working on using the runtime predicates in interchange. 



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