[Mlir-commits] [mlir] [mlir] Add normalize pass to MLIR (PR #186647)

[lonely eagle]

linuxlonelyeagle wrote:

> I'm slightly worried about the recursive complexity. 

I believe that through pruning, we can achieve O(1) time complexity. Each op should only be tried for relocation once; once we’ve moved it, we definitely won't touch it again.

> If we allow original ops moving over each other, could this have unstable results?

We should not allow this. As I understand it, doing so would imply allowing operations with side effects to reorder with respect to one another.

> @arun-thmn has a similar pass for x86, but there are some differences on how much to actually move around. My concern here is that the sequence of IR will make a difference at the instruction scheduling at the lower levels, so some movements are good, others may hurt. (we have seen this when lowering to LLVM).
> 

Make sense. However, this pass is ported from LLVM's normalize pass, and its purpose is to transform IR into a normal form that's easier to diff. We use it to observe whether two sets of IR are functionally identical.

> Final note is about moving ops across different regions. Control flow region semantics are more well known, but what if the region is inside an op where the semantics isn't clear? For example, it changes the address space, or there's an implicit communication barrier, etc?

I expect the current implementation won't change it, as it only considers the impact of memory writes and only relocates pureOps. As for address space operations or memory barriers like nvgpu.device_async_wait—they won't be moved. Even if they don't explicitly state their side effects, the fact that they aren't marked as pure implies potential side effects.

Please let me know if I’ve misunderstood anything. I’m eager to learn more about this, as I’m not very familiar with instruction scheduling.❤️


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