Jank now has its own custom IR
50 points by DASD 3 days ago | 4 comments

CalChris 42 seconds ago
[delayed]
reply
christophilus 3 hours ago
> we're using it to optimize jank to compete with the JVM

The JVM gets a lot of hate, but that is a very high bar. The JVM is a serious piece of kit. I hope Jank succeeds. I'd love to use it in real projects.

reply
lemming 3 hours ago
Great article, as always.

There is one thing that I think is important to bear in mind when discussing inlining, especially in the context of Clojure. This is that once a function has been inlined, you can no longer update the definition of that function in the REPL and have that update the behaviour of functions which use it, unless you recompile those as well. This is not a criticism of course, it’s just part of the natural tension between dynamism and performance.

reply
thfuran 2 hours ago
Does that not happen automatically? I know there are contexts in which jvm will deoptimize inlining and recompile, like in response to class loading that causes a call site that was previously provably monomorphic to no longer be.
reply
sieabahlpark 2 hours ago
[dead]
reply
mccoyb 3 hours ago
Hoping to understand this better:

> Clojure's dynamism is granted by a great deal of both polymorphism and indirection, but this means LLVM has very few optimization opportunities when it's dealing with the LLVM IR from jank.

In my mind, what is happening here is you lower Clojure code into LLVM, with a bunch of runtime calls (e.g. your `jank::runtime::dynamic_call`) (e.g. LLVM invoking the runtime over a C ABI).

If that's true, are there any optimizations that LLVM helps out with? Perhaps like DCE? I can't tell immediately, curious about the answer

(question is obviously about the pre-IR state of things)

reply