[llvm] [Passes] Move LoopInterchange into optimization pipeline (PR #145503)

[Ryotaro Kasuga via llvm-commits]

kasuga-fj wrote:

As tested with the llvm-test-suite, this patch **reduces** the number of interchanged loops by one. The omitted transformation corresponds to the following loop in  `llvm-test-suite/MultiSource/Applications/obsequi/tables.c`:

```c
for (i = 0; i < 32; i++)
  for (j = 0; j < 32; j++)
    for (k = 0; k < 2; k++)
      fill_in_key_entry(&g_keyinfo[k][i][j], n_rows, n_cols);
```

This change is due to the ordering between full unrolling and loop interchange. In the original pipeline, the k-loop is lifted to the outermost position because doing so improves data locality. On the other hand, with this patch, the k-loop is fully unrolled first, preventing the interchange from being applied. While it's unclear to me which behavior is preferable in general, in this case, performance remained largely unaffected.

I think LoopInterchange should not be in the simplification pipeline because loop versioning may be introduced inside the LoopInterchange in the future (ref: https://github.com/llvm/llvm-project/pull/123436), which is better suited to the optimization pipeline. Additionally, if we're going to change its position, I believe we should do it before https://github.com/llvm/llvm-project/pull/124911, which is the primary motivation behind submitting this patch now. Or should we wait until it actually becomes a problem?

> This should also at least have a test checking the position of LoopInterchange in the pipeline

Exactly, I'll add it. Just to confirm, are you referring to a test like https://github.com/llvm/llvm-project/blob/559218f7ee78f77d32c14cd14a56b799167596f5/llvm/test/Other/new-pass-manager.ll ?

>  ideally a phase-ordering tests that shows an improvement

I agree with it, but performance improvement is not a purpose of this patch, and I don't have a good example for it...

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