I’m trying to write a simple code shrink phase to ...

# kotlin-native

[Landerl Young]

I’m trying to write a simple code shrink phase to K/N compiler, but met servral problems. Could someone give me some help.

I planed to do a Markup Sweep algorithm to detect dead code. But I found that the shrink phase must be operated on bit code instead of IR in order to shrink library code.

However the bitcode contains much more data than simply class and methods (lke java byte code), which makes the shrink phase much hard.

Especially the TypeInfo, OC export, CStubs, etc... That makes Class/Function removal more hard.

And also, it seems impossible to remove virtual methods, since which would change the vtable structure, and make the existing method index invalid.

I’m new to K/N compiler (but experienced on K/N itself), the compiler do steps like SourceCode -> PSI -> IR -> bitcode.
I’m curiousied that what is the IR. Is it LLVM-IR, or just a Jetbrain defined IR shared with Kotlin/JVM？

To sum up, my questions is:
1. How to deal with OCExport,CStubs etc, when a Class/Function is removed.
2. How to remove virtual methods.
3. What is the DFG?
4. To shrink bitcode, can I take advantage of DFG or IR in the Context?

[Landerl Young]

One more question: how to debug compiler inside IntelliJ？ thanks～

[Landerl Young]

One simpy and crazy yet efficiency solution is to load all library IR together and recompile, do code shrink on the IR level，but it will make compile time much longer.

[olonho]

Code shrinking in K/N better be combined with new codegenerator, see this branch for ongoing work in this direction: https://github.com/JetBrains/kotlin-native/tree/codegen_whole_ir

[olonho]

Here proper DCE could be done on level of IR, which our own IR, shared between Native and other (JVM, JS) backends.

[olonho]

If you want to debug compiler from IDE, it generally work, if you select Gradle tasks with tests, i.e. args0 and debug as usual.

[Landerl Young]

Thanks very much.

If to work on the IR level, how to eliminate code from klibs？Since their bitcode is already generated. Maybe recompile them from IR like I talked previously.
Currently I'm trying to do this on the linkage stage.

[olonho]

The change I refer above aims to remove significant part of bitcode from .klibs, so generally I’d suggest for it to be merged (likely sometimes next week) before doing further work.

[Landerl Young]

Thanks for the info～It's a doable plan！