2 questions I have regarding to an hypothetic Kotlin -> Kotlin IR -> Binaryen IR -> WebAssembly toolchain: - How much Kotlin/Native is tide to LLVM? Could we imagine some kind of Kotlin/Native IR not tide to LLVM that could be used to generate Binaryen IR when targeting WASM? - I heard that Kotlin/JS team is working on an IR, is there some kind of generic Kotlin IR effort or is it specific to Kotlin/JS?

I heard that Kotlin/JS team is working on an IR, is there some kind of generic Kotlin IR effort or is it specific to Kotlin/JS?

Its a general effort to transition all backends to Kotlin IR. It would enable more code reuse across backends, common library format and common compiler plugin API. Moreover, new Kotlin/JS backend on top of this IR is almost done, stay tuned.

Awesome ❤️

Could we imagine some kind of Kotlin/Native IR not tide to LLVM that could be used to generate Binaryen IR when targeting WASM?

When IR comes out of frontend it is almost backend agnostic for “pure” Kotlin code. Down the road it is lowered somewhat differently for each backend to enable simple Kotlin IR to JVM Bytecode, JS AST or LLVM IR conversions. Almost everything interop related is handled differently. In order to have direct WebAssembly generation one would want to add/delete/tweak some of these later lowering passes to get adequate IR abstraction level for WebAssembly code. I’m not sure how much should be changed in K/N but it would vary greatly depending on number of post-MVP WebAssembly features enabled.

I will try to analyze what Kotlin/JS and Kotlin/Native features would map to WebAssembly post-MVP and how

Another big thing IMO is interop. Future Wasm version might enable interop with JavaScript, unmanaged Wasm and managed Wasm compiled from other languages at the same time. Design of Wasm represenation for Kotlin constructs might affect this a lot.

Yeah I plan to take inspiration on what Rust do