|
A couple of remarks. For all the praise LLVM gets, already in the mid-70's compiler based frameworks were a thing, IBM PL.8 RISC project, and early 1980's Amsterdam Compiler Toolkit are two notable examples of similar stacks. Go would still exist, because Google would never picked D for their cloud projects, and its adoption grew from Go creators working at Google. See how sucessfull Oberon and Limbo projects from the same authors were, before their Google days. While C++, Java and .NET now have most of the features that D was known for when Andrei Alexandrescu published his Programming in D book, I still think the execution in D is better packaged, although yeah, wihtout the related ecosystem and IDE tooling, it is an hard sell. Maybe "slow and steady" still will surprise us, like it took Rails to make Ruby known outside Japan, or maybe it is too late no matter what. Future will tell. |
LLVM has the core IR structure as an in memory structure and as a text format and as a binary format. The easy, lossless (modulo partial implementation of new features) conversion between the formats was a really big deal. I'd be interested to hear of prior art on it.
In particular, it means developers can diff the IR between passes and generally apply textbased tooling to it during debugging, and you can do things like link time optimisation really easily by combining separate files then running them through the optimiser.
LLVM is creaking a little under its age, and I don't think it's ideal that it's written in C++, but the flexible architecture is legitimately better than I've seen in other compilers. In particular, it has been a competitive edge over GCC.