How stable is the LLVM assembly language?

Question

The LLVM Language Reference states that it can be used

as an on-disk bitcode representation (suitable for fast loading by a Just-In-Time compiler)

How stable is this representation? E.g., can I generate it today using LLVM 3.1 and still expect it to be usable using a future LLVM, say a hypothetical LLVM 4.5 in three years?

Assuming I don't have external dependencies, can I use it to generate a binary for a different architecture?

Answer 1

Answer to your first question: No. It's not stable. No, you can not expect that IR/bitcode generated by 3.1 will be readable in 4.5 - the LLVM project explicitly does not make this guarantee, sacrificing backwards compatibility in favor of the ability to move forward faster, create better optimizations and tools, and refactor parts of the framework as needed. LLVM is primarily targeted at static, ahead-of-time (AOT) compilers, so this approach makes sense for the big players.

The second question I don't really understand. LLVM has targets (backends) for many architectures, and works well for most of the popular ones. But again, their input is IR which is subject to change between releases. Also make sure to read this: http://llvm.org/docs/FAQ.html#can-i-compile-c-or-c-code-to-platform-independent-llvm-bitcode, and also the "Target dependence" section here: https://llvm.org/docs/tutorial/LangImpl10.html

The problem is that when asking about LLVM platform independence many people ask "will LLVM IR compiled from my C code be target independent?". The answer to this is No, because C itself is target dependent.

Answer 2

Answering your first question: here is a cite from the LLVM Developer Policy.

When the IR format has to be changed, keep in mind that we try to maintain some backwards compatibility. The rules are intended as a balance between convenience for llvm users and not imposing a big burden on llvm developers:

• The textual format is not backwards compatible. We don’t change it too often, but there are no specific promises.
• The bitcode format produced by a X.Y release will be readable by all following X.Z releases and the (X+1).0 release.
• Newer releases can ignore features from older releases, but they cannot miscompile them. For example, if nsw is ever replaced with something else, dropping it would be a valid way to upgrade the IR.
• Debug metadata is special in that it is currently dropped during upgrades.
• Non-debug metadata is defined to be safe to drop, so a valid way to upgrade it is to drop it. That is not very user friendly and a bit more effort is expected, but no promises are made.