3 ms·

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.

michielderhaeg 2y ago
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 https://llvm.org/docs/OpaquePointers.html
- fooker 2y ago
  IR can be auto-upgraded between LLVM versions.
  - almostgotcaught 2y ago
    citation? i work on LLVM (like llvm/llvm-project) and i'm not aware of such a tool.
    - theresistor 2y ago
      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-compatibility https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-comp...
      - almostgotcaught 2y ago
        bitcode policy i'm aware of - it's the "IR" part that caught my attention.
        mannycalavera42 2y ago
        a pretty evident case of not almost got caught
fooker 2y ago
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.
- michielderhaeg 2y ago
  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.
- michielderhaeg 2y ago
  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.
  - almostgotcaught 2y ago
    > 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.

michielderhaeg 2y ago

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 https://llvm.org/docs/OpaquePointers.html

fooker 2y ago
IR can be auto-upgraded between LLVM versions.
- almostgotcaught 2y ago
  citation? i work on LLVM (like llvm/llvm-project) and i'm not aware of such a tool.
  - theresistor 2y ago
    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-compatibility https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-comp...
    - almostgotcaught 2y ago
      bitcode policy i'm aware of - it's the "IR" part that caught my attention.
      - mannycalavera42 2y ago
        a pretty evident case of not almost got caught

fooker 2y ago

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.

michielderhaeg 2y ago
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.
michielderhaeg 2y ago
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.
- almostgotcaught 2y ago
  > 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.