I don't think there's anything we need to do here that couldn't be expressed in MLIR representationally. That said, I also haven't studied MLIR's representation in too much detail myself, so it's possible there's subtle corner cases. For example, in LLVM you end up getting quadratic processing times even for linear time passes, because it needs to restore the ordering count for instructions (I think the trick in this PR may be backportable to LLVM to improve that, but I haven't looked into it yet). We ran into that badly with larger functions, so it's possible there'd be similar corner cases in MLIR if we used it e.g. for the tree structuring that's proposed in this PR.

Not using MLIR here is more about other considerations:

1. It'd probably be more of a pain to write high performance bindings than just to write the data structure in julia itself.

2. We will be targeting WasmGC in the near future, so we need our core runtime and compiler data structures to be compilable without the assumption of necessarily having linear memory available.

3. It's designed to be used by downstream julia users, so it's easier for them to not have to deal with another system in another language.

4. It's experimental and we need to be able to make changes quickly without having to necessarily have a big upstream discussion.

That said, like I mentioned in the other comment, easy interop with MLIR is an explicit design goal.