Most active commenters
  • michielderhaeg(3)
  • almostgotcaught(3)

←back to thread

Jank development update – Moving to LLVM IR

(jank-lang.org)
188 points refset | 11 comments | 15 Oct 24 06:50 UTC | HN request time: 0.007s | source | bottom
1. RossBencina ◴[17 Oct 24 07:12 UTC] No.41867167[source]▶
Is LLVM IR a stable target these days? I once heard of a project that got bit pretty hard with LLVM IR interface changes in the (not all that recent) past.
replies(2): >>41867338 #>>41867511 #
2. michielderhaeg ◴[17 Oct 24 07:45 UTC] No.41867338[source]▶
Absolutely not. They do invasive changes all the time. At work we maintain an LLVM compatibility library that provides a stable interface across different LLVM versions. It has grown quite big over the years. The pure C interface is in comparison much more stable, but also quite limited.

Not just the API changes, the LLVM IR syntax can change drastically as well. E.g. not too long ago they switched from types pointer types to opaque pointers. `i32*` just becomes `ptr`. [1]

[1] https://llvm.org/docs/OpaquePointers.html

replies(1): >>41867508 #
3. fooker ◴[17 Oct 24 08:20 UTC] No.41867508[source]▶
IR can be auto-upgraded between LLVM versions.
replies(1): >>41868402 #
4. fooker ◴[17 Oct 24 08:21 UTC] No.41867511[source]▶
As long as you use the C++ API, the pace of change is reasonable.

If you try to keep by by generating textual IR, it can be a nightmare.

replies(2): >>41867925 #>>41867947 #
5. michielderhaeg ◴[17 Oct 24 09:40 UTC] No.41867925[source]▶
I think the bitcode parsers (binary and textual) are quite backwards compatible. Old bitcode IR will be upgraded transparently. So you might not have to keep up.
6. michielderhaeg ◴[17 Oct 24 09:43 UTC] No.41867947[source]▶
I do agree that the pace is reasonable. Both with opaque pointers and the new pass manager API there was a quite a long transition period where both were supported before the old system was deprecated/removed. But with every new non-patch release, some part of the public API is changed and we have to adapt.
replies(1): >>41868454 #
7. almostgotcaught ◴[17 Oct 24 11:05 UTC] No.41868402{3}[source]▶
citation? i work on LLVM (like llvm/llvm-project) and i'm not aware of such a tool.
replies(1): >>41868681 #
8. almostgotcaught ◴[17 Oct 24 11:13 UTC] No.41868454{3}[source]▶
> But with every new non-patch release, some part of the public API is changed and we have to adapt.

bumping only on major release is recipe for pain and misery. everyone project i'm familiar with bumps weekly against HEAD. much more manageable.

9. theresistor ◴[17 Oct 24 11:42 UTC] No.41868681{4}[source]▶
The textual IR is not backwards compatible, but the bitcode format has been best-effort auto-upgradeable for as long as I've been involved (2006). The policy is documented here: https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-comp...
replies(1): >>41868980 #
10. almostgotcaught ◴[17 Oct 24 12:23 UTC] No.41868980{5}[source]▶
bitcode policy i'm aware of - it's the "IR" part that caught my attention.
replies(1): >>41869160 #
11. mannycalavera42 ◴[17 Oct 24 12:47 UTC] No.41869160{6}[source]▶
a pretty evident case of not almost got caught