←back to thread

188 points refset | 2 comments | | HN request time: 0s | source
Show context
RossBencina ◴[] 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 #
michielderhaeg ◴[] 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 #
fooker ◴[] No.41867508[source]
IR can be auto-upgraded between LLVM versions.
replies(1): >>41868402 #
almostgotcaught ◴[] No.41868402[source]
citation? i work on LLVM (like llvm/llvm-project) and i'm not aware of such a tool.
replies(1): >>41868681 #
theresistor ◴[] No.41868681[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 #
1. almostgotcaught ◴[] No.41868980[source]
bitcode policy i'm aware of - it's the "IR" part that caught my attention.
replies(1): >>41869160 #
2. mannycalavera42 ◴[] No.41869160[source]
a pretty evident case of not almost got caught