[llvm-dev] bitcode versioning

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Thu Dec 3 07:45:15 PST 2015

> On Dec 3, 2015, at 4:10 AM, Manuel Rigger via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> Hi all,
> I am implementing a LLVM IR interpreter and have the following problem: I want to support execution of bitcode files targeted towards different LLVM versions. For example, a user of the interpreter should be able to compile a C file with the latest version of Clang, a Fortran file with Dragonegg (targeting LLVM 3.3), and a Haskell file with GHC (targeting LLVM 3.5), and then just feed it to my interpreter without additional arguments.
> Currently, my parser expects textual representation for a specific LLVM version. I could provide different parsers or parser configurations that support different bitcode versions, but there is no notion of a version field in the textual representation that I could use to determine which parser to use. Anyway, for the long term it is not a good idea to rely on the textual format due to the missing backward compatibility guarantees.
> Hence, I want to replace the textual format parser with a parser for bitcode, which would also be able to parse the files of my example. But how should I treat bitcode files of major upcoming releases, e.g., of LLVM 4.1? I found a version ID in the bitcode wrapper format, but the documentation states that the ID is currently always 0. Is there a policy that specifies when the ID will be updated? Without having such a policy in place, I would just postpone the problem I currently have with the textual format parser.

The wrapper format is Darwin specific AFAIK. However starting with 3.8 there will be a another version block in the bitcode, which contains a string identifying the producer and an integer that will be bumped when needed (whatever it means).
Look for lib//Bitcode/Reader/BitcodeReader.cpp:llvm::getBitcodeProducerString() as a starting point.


More information about the llvm-dev mailing list