Are there any pros/cons to using the new IR backen...

# announcements

[Sam Garfinkel]

Are there any pros/cons to using the new IR backend right now? Once the compiler API is stabilized obviously we’ll want to use the IR backend to support multiplatform plugins, but are there any benefits currently?

[Robert Jaros]

If you target JS, you get much smaller bundle size.

[Sam Garfinkel]

Does it run DCE as part of the transpiler process or is the generated code simply smaller?

[Robert Jaros]

It is smaller even before DCE.

[udalov]

There are several classes of issues which we've fixed in the new backend by completely rewriting the underlying code. If you saw, and/or had to workaround an error from the old JVM backend such as "wrong bytecode generated", or "AnalyzerException" -- it might be the case that this is fixed in the new IR backend.

Some examples of these categories of issues are:
1) Complex structures of local classes, local functions and captured values (e.g. https://youtrack.jetbrains.com/issue/KT-21778)
2) Compound assignment operators & nullability and/or indexed operator functions (e.g. https://youtrack.jetbrains.com/issue/KT-19861)
3) Many issues where inline classes are not boxed or unboxed properly (e.g. https://youtrack.jetbrains.com/issue/KT-35533)

Not all problems are fixed in the new backend, but we believe that the foundation is good enough that there's much less of these kinds of problems there now.

Of course, the new JVM IR backend will inevitably introduce some new issues, but this is where we need your help, to opt-in and help us find them before the release. We do believe that because of the common backend code that we've been using and testing for a long time now (Kotlin/Native started on the common IR backend and has been using it since), new issues are going to be much more "corner-case"-like than in the old backend.

In some other examples, the tail call optimization in coroutines is more intelligent in the new backend (because it's easier to determine if a function is a tail-call looking at the IR vs the JVM bytecode), and local functions no longer cause a new object to be instantiated (https://youtrack.jetbrains.com/issue/KT-6336).

The main remaining problem of the JVM IR backend is the fact that the generated API and ABI have a few differences with the old bytecode, so it's not fully binary compatible with the old backend. Especially with things like inheritance from standard collection interfaces where we do some dirty hacks like renaming methods and adding custom checks to their bodies. This is why we've "poisoned" the newly generated bytecode, so that you wouldn't be able to depend on it in modules compiled by the old backend. We plan to fix all these differences before we enable JVM IR by default, and be fully forwards- and backwards-compatible with Kotlin and Java of previous versions.