We have our own C++ language extension (based on Clang 3.2) and its special backend (implemented in LLVM 3.2). Now we want to upgrade Clang to version 3.3 or 3.4, and the backend (llc) is still remained in LLVM 3.2. (aka. compile our own C++ language extension to LLVM 3.3/3.4 IR, and use LLVM 3.2 llc to generate its special backend assembly). I already know that LLVM assembly has different syntax of attribute from LLVM 3.3 and LLVM 3.4 has a new instruction - addrspacecast. I am wondering how to know the exhausted incompatibility of LLVM IR?
I am wondering how to know the exhausted incompatibility of LLVM IR?
Unfortunately, you're probably going to have a very hard time of it.
Compatibility in that direction isn't something LLVM either tries to
maintain or document. We try to make sure older bitcode files will
compile with newer versions of LLVM, though even that only works to an
The IR itself doesn't change *very* regularly (running "git log
docs/LanguageReference.rst" would give some idea of what's happened
since 3.2 -- I see ~150 since the 3.2 era). But how it's interpreted
and what backends are expected to cope with is more in flux. And the
API is almost certainly very different, so doing it all in a single
process would lead to a world of pain.
For what it’s worth, Android maintains an LLVM 3.2 bitcode writer (https://android.googlesource.com/platform/frameworks/compile/slang/+/master/BitWriter_3_2/). I recently updated this to work with upstream LLVM @r209713. I know that there are a few interested parties that would love to see this decoupled and published as a separate library/utility, since there are now many projects that chose ~3.2 as a relatively stable bitcode format. Unfortunately, I never seem to have the time to be able to put it into a separate form that would be suitable for other projects to use.