[llvm] [LoopInterchange] Enable it by default (PR #124911)

[Ryotaro Kasuga via llvm-commits]

kasuga-fj wrote:

@sjoerdmeijer What compilation options and target did you use? The result of `LoopCacheAnalysis` heavily depends on the cache line size, which is retrieved via `TargetTransformInfo`. In my experience, the profitability check doesn't work well when the cache line size is 0, and IIUIC, some targets set it to 0 by default. Changing it to a non-zero value may increase the number of loops that can be interchanged. I also have some relatively easy-to-implement ideas to relax the legality checks to accept more patterns, but I'm not sure if it will be beneficial in practice.

Regarding the compile-time increase, I also think it's quite significant, and there is still room for improvement. Here are some suggestions:

- Delay the computation of `LoopCacheAnalysis` until it's actually needed. I did a quick test on `CMakeFiles/lencod.dir/q_matrix.c.o`, which causes a significant increase in compile time, and this approach seemed very effective at least for this case.
- IIUIC, DA doesn't cache its results. Both `LoopCacheAnalysis` and `LoopInterchange` appear to query DA with the same inputs, so caching these results might help reduce compile time.
- `LoopInterchange` uses a bubble sort–like algorithm to select candidate loops to be exchanged. This can result in the same pair being evaluated multiple times, so caching may also help here.
- At the moment, setting a smaller default value for `MaxMemInstrCount` seems reasonable to me.
- As @artagnon suggests, there are opportunities for early exits. For example, if a direction vector is composed entirely of `*` (e.g., `[* * *]`), continuing the analysis obviously doesn't make sense. Skipping such cases could reduce the number of queries to DA.

For now, I'll work on the first one. As for the others, I haven't tried them and I'm not sure if they will really help, but I believe they are worth investigating.

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