3 ms·

Klee is also a great example of the cost of LLVM's never-backwards-compatible approach: according to their home page, the stable release of Klee runs on 3.4 and

Klee is also a great example of the cost of LLVM's never-backwards-compatible approach: according to their home page, the stable release of Klee runs on 3.4 and 3.8 is "experimental". (The LLVM releases since then have included: 3.9, 4.0, 5.0, 6.0, and 7.0.) Don't get me wrong, LLVM is great, but I really wish that as the project matured they had made more of an effort to provide some level of compatibility. As it is, it's a massive pain for open source projects to follow along.

jcranmer 8y ago
If you compile a bitcode file from anywhere around LLVM 3.3 or later, you can generally read it in the most up-to-date version of LLVM (you may have to first strip debugging metadata though). The LLVM-C API also maintains compatibility, but that comes at the steep cost of preventing you from using most of the power: LLVM-C is basically limited to reading/writing LLVM code, running passes largely at the -O1/-O2/-O3 level of granularity, and executing the JIT. Writing a pass with that API is very difficult, and pretty much impossible if you want to use any analyses.
jclay 8y ago
That's a good point. Most of the large LLVM projects I've used (such as Root's Cling) seem to lag behind LLVM's versions rather drastically.
drmeister 8y ago
Counterpoint - I implemented a Common Lisp compiler that uses llvm as the back end (https://github.com/clasp-developers/clasp https://github.com/clasp-developers/clasp). I've kept up with the versions from 3.6 to 6.0 and I'm about to upgrade to 7.0. I'm not sure why other projects find this difficult but I have noticed that if I get too far behind it does get a bit more difficult. I exposed the C++ API to Common Lisp and write all of the compiler in Common Lisp. The Clang C++ compiler tells me what is broken when I upgrade to a new version of llvm and then I fix it. I talk about it here https://www.youtube.com/watch?reload=9&v=mbdXeRBbgDM&feature=youtu.be https://www.youtube.com/watch?reload=9&v=mbdXeRBbgDM&feature... at about 13:30

jcranmer 8y ago

If you compile a bitcode file from anywhere around LLVM 3.3 or later, you can generally read it in the most up-to-date version of LLVM (you may have to first strip debugging metadata though). The LLVM-C API also maintains compatibility, but that comes at the steep cost of preventing you from using most of the power: LLVM-C is basically limited to reading/writing LLVM code, running passes largely at the -O1/-O2/-O3 level of granularity, and executing the JIT. Writing a pass with that API is very difficult, and pretty much impossible if you want to use any analyses.

jclay 8y ago

That's a good point. Most of the large LLVM projects I've used (such as Root's Cling) seem to lag behind LLVM's versions rather drastically.

drmeister 8y ago

Counterpoint - I implemented a Common Lisp compiler that uses llvm as the back end (https://github.com/clasp-developers/clasp https://github.com/clasp-developers/clasp). I've kept up with the versions from 3.6 to 6.0 and I'm about to upgrade to 7.0. I'm not sure why other projects find this difficult but I have noticed that if I get too far behind it does get a bit more difficult. I exposed the C++ API to Common Lisp and write all of the compiler in Common Lisp. The Clang C++ compiler tells me what is broken when I upgrade to a new version of llvm and then I fix it. I talk about it here https://www.youtube.com/watch?reload=9&v=mbdXeRBbgDM&feature=youtu.be https://www.youtube.com/watch?reload=9&v=mbdXeRBbgDM&feature... at about 13:30