This is (in my humble opinion) a fantastic introduction, and relevant to a much wider audience than the title implies. If you want to keep up to date with LLVM developments, you might also be interested in my LLVM Weekly newsletter (<a href="http://llvmweekly.org/" rel="nofollow">http://llvmweekly.org/</a>). I try to highlight interesting commits, mailing list discussions, and blog posts (tips and submissions always welcome!).
Adrian might have mentioned an important drawback of using LLVM: active effort is required to keep up with it. Many an LLVM-based research project has gotten stuck on 2.9 or 3.2 at which point it starts becoming less and less relevant.<p>It's not that big of a deal, but active effort is required. The amount of effort depends on how many and which APIs your project uses; for a small/medium project perhaps a couple of hours every couple of weeks.
For the past year, i had two projects which required me to work with LLVM. Because of the scarcity of articles/documentation, i found it really hard to get into it. The API Docs and a few articles by Eli Bendersky(thank you so much!!! ) was all i found useful.<p>But once i got past the basic hurdles, the llvm project code was so well written, i felt a certain pleasure working with it.
A nice introduction, I'm currently working on a compiler which uses LLVM for code generation... it was very difficult to get into at first. Especially since I was using C (now Go), so I would have to work through 2/3 layers of language and documentation. (Was just C to C++, now it's Go, to C, to C++).<p>If you're interested in learning more about LLVM, there are some good open source projects that use it. If you aren't using C++, people have also ported the kaleidoscope tutorial project to Haskell, Rust, C, etc... Additionally, a lot of bigger compilers like Rust, and Clang use it - Swift also uses LLVM, and should be open source soon?
This is a great intro into the subject.<p>We use LLVM to at MapD (<a href="http://mapd.com" rel="nofollow">http://mapd.com</a>) to compile SQL queries to CPU and GPU machine code - it has given us a major boost over an interpreter based approach. For more see here - <a href="http://devblogs.nvidia.com/parallelforall/mapd-massive-throughput-database-queries-llvm-gpus/" rel="nofollow">http://devblogs.nvidia.com/parallelforall/mapd-massive-throu...</a>. If you have a background in LLVM or compilers in general and are interested in tackling problems like this please reach out at jobs@mapd.com.
If you're really interested in this stuff and looking for an opportunity, we're looking for talented LLVM developers for our Austin location.<p><a href="http://www.bitfusion.io/jobs.php" rel="nofollow">http://www.bitfusion.io/jobs.php</a><p>Mazhar Memon, Bitfusion.io
> LLVM is nicely written: its architecture is way more modular than other compilers. Part of the reason for this niceness comes from its original implementor, who is one of us.<p>What on earth is that supposd to mean?
This is indeed a great intro article.<p>For those interested in seeing examples of LLVM hacking in action, I would recommend reading the source for Halide – <a href="https://github.com/halide/Halide" rel="nofollow">https://github.com/halide/Halide</a> – which is an image-processing DSL implemented in C++ and piggybacking on LLVM. I myself learned a lot about LLVM this way.
This isn't germane to the main topic but this paper they cite about using a compiler pass to verify OS security ("Protecting Applications from Hostile Operating Systems") is pretty darn interesting: <a href="http://sva.cs.illinois.edu/pubs/VirtualGhost-ASPLOS-2014.pdf" rel="nofollow">http://sva.cs.illinois.edu/pubs/VirtualGhost-ASPLOS-2014.pdf</a>
Long time ago I read a post by Mathew Flatt about LLVM and gcc and how mini optimization and selling points were important not able to find the post, but it was a interesting read.