Hi all,
I found Kotlin use pseudo as “IR” in front end. I’m confused about why kotlin uses it and waht is pseudo.
Is there any documents dedicated to the Kotlin pseudo?
Thank you in advance!
1 Like
It’s not pseudocode per se, in fact I haven’t heard of any mention of pseudo relating to the Kotlin compiler. Maybe you misheard PSI? Let me explain the different representations in the Kotlin compiler:
-
At the very start: There’s the old frontend and the old backend. The old frontend simply uses IntelliJ PSI (Program Structure Interface). This representation simply represents a Kotlin program as elements of the code itself (stuff like brackets, parenthesis, identifiers (i.e. names), modifiers (e.g. public, inline, fun, etc)). Simply, this PSI representation is solely based on the textual information from the .kt file, without any resolution information about what the code is actually referring to. Then, still in the old frontend, an analysis phase happens that resolves all these class and checks the code for errors and stuff like that, and then the PSI along with the analysis information (which is stored in the
BindingTrace) is passed to the old backend to be translated into each platform’s respective “bytecode” (Java bytecode, Javascript, and LLVM IR for Kotlin/JVM, Kotlin/JS, and Kotlin/Native respectively). -
Then, we have the point that we are at today, which is that we have a new backend, but still with the old frontend. The frontend still does all the analysis and PSI stuff, but then the new backend converts that information into a new Intermediate Representation (IR) that then the Kotlin compiler performs some transformations on for all the backends (stuff like optimising for loops for example and just other optimisations and simplifications that aren’t platform dependent). Then after the common transformations (called Lowerings internally) are done, the platform-specific lowerings are done (for example, removing typealiases since they don’t exist on the JVM). Finally, the IR is then compiled into each platform’s bytecode.
-
This is where the Kotlin team hopes to be in a year or two, which is having the new frontend . Simply, the future should be that the Kotlin compiler will be using the new frontend with the new backend. The new frontend does technically use PSI (If I remember correctly), but that’s just at the very start of the pipeline, because then it transforms it into FIR (Frontend Intermediate Representation). This FIR contrains analysis information along with the code, and allows for more complex transformations to be done in the frontend of the compiler. The cool thing about FIR is that it will have good integration with the IDE, and so if you have a FIR plugin, it will be able to for example add a brand new method to a class or change how call resolution works or anything like that that is frontend-related, and the IDE will just understand that and surface it to the user normally.
2 Likes
Ohh, interesting. I’m far from being an expert in this field, but I always though it is kind of standard for compilers to go this way: source code → tokenized source code (PSI?) → AST → IR → native/bytecode/etc. Why does it seem so different in the case of Kotlin? Or maybe it is the same, but just the naming is a little different?
1 Like
PSI is already kind of an AST basically. Kotlin at first didn’t really need a full on IR because it was compiling to only the JVM. Then when K/JS came along it was just kind of cobbled together without creating an IR. But then with K/N, the team created an IR because it was massively helpful since they were dealing with Native code.
1 Like