[PATCH] D132199: [LoopPassManager] Ensure to construct loop nests with the outermost loop

[Arthur Eubanks via Phabricator via llvm-commits]

aeubanks added a comment.

Sorry, I'd meant to reply but didn't find time, I'll try to be more prompt about responding to this

This is definitely better than the previous version.

IMO it would still be best if continually rerunning a pass on some IR would reach a fixed point. For example, when loop unswitching happens, we revisit the current loop (which means restarting the entire loop pipeline), and if we end up creating a new loop, we also add that new loop to the worklist. There has been care taken to ensure that unswitching cannot run forever. If interchange did this, we'd be able to just revisit the entire loop nest again. For the interchange example, you say that loop-interchange may continually swap between `L1(L2)` and `L2(L1)`, one of them must be better than the other, why can't we converge on the better nesting? I don't quite understand the "locality vs vectorization" argument, there still must be one nesting that's ultimately optimal in the end. Then we can restart the pipeline on the loop nest, or just the loops that got swapped around.

But if that doesn't make sense, then something along these lines seems ok. I think it might be worth revisiting exactly how loop nest passes work, but I haven't thought too hard about it. But then again, this seems like a loop-interchange-specific issue, not a loop nest issue.

also you'll have to rebase again since my patch was reverted
also seems like we've dropped the test?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132199/new/

https://reviews.llvm.org/D132199