[KenoFischer]

Uh, hi guys. This is my PR, but you should probably know that this is an AI generated prototype based on some of my design documents, but nowhere near ready for prime time. I do want to do something like this, but whether it'll take this shape or another is still up in the air.

[mccoyb]

Very cool work Keno! Any place to find information about the Julia-specific concepts / features compared to MLIR?

Wondering if there are modeling or analysis modalities that don’t fit cleanly into MLIR concepts (understand that abstract interpretation on the IR comes with a unique set of concerns)

[KenoFischer]

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.

[Archit3ch]

> 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.

Big if true. Does that mean we'll get a no-alloc iOS backend?

[KenoFischer]

I'm not sure I understand the connection, but I also know basically nothing about iOS.

[Archit3ch]

1. iOS doesn't allow JIT for apps distributed through the App Store. However, WASM (including JIT) is allowed. Effectively, this would allow Julia to run on i(Pad)OS.

2. Technically, one could port the Julia compiler itself to WasmGC and get full REPL/eval semantics. However, App Store Guideline 2.5.2 states "Apps [...] nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps.". It's not clear if this only applies to downloaded code or also local code (e.g. a playground app). If you attempt it, there is a good chance Apple will update their guidelines specifically to ban it. :P

[andyferris]

1. Don't forget that there are parallel efforts for static compilation in Julia - a static artifact should be able to get through the App Store.

[gregdaniels421]

The WasmGC and the lack of good support in LLVM is a pain, but having yet another IR may be worse decision in the long run compared with just using MLIR and submitting changes to have it work for you

[KenoFischer]

Not sure the MLIR folks would appreciate a vibe-rewrite PR from C++ into Julia, but guess we could give it a go ;).

[gregdaniels421]

It would be more of just use MLIR and if you need some extensions for something upstream the changes needed.