As a Rust enthusiast and someone who frequently works with and on many parts of LLVM, this topic obviously catches my attention. I was and remain very unconvinced, though. I've not been able to synthesize a coherent thesis, but here's a scattering of relevant aspects:
-
One of the biggest boons of LLVM is that it is a de facto standard in industry and research. It's hard to overstate how many people are agreeing on using LLVM and how much this consensus helps all involved: there's mountains of experience, shared code, interoperability, cooperation, etc. in and around LLVM and its community. Any rewrite that does not have the full backing of the LLVM community automatically loses this.
-
LLVM's design is not bad, don't get me wrong, but it's far from perfect. Without even deviating from its "core design philosophy", there are many things in all parts of LLVM that would have changed for the better if not for inertia. Even the improvements that were decided on sometimes stall (e.g., removal of pointee types). A from-scratch rewrite that unquestioningly inherits LLVM's design would waste a great opportunity to learn from hindsight (just as LLVM benefited from hindsight wrt to earlier compiler projects).
- And this is without even going into the many ways one could overthrow fundamental assumptions of LLVM (e.g., the "linear" IR vs a sea-of-nodes IR, or three address IR vs RTL).
-
While LLVM IR and the target-independent passes operating on it is obviously a big and important part of LLVM, the target-dependent parts are usually under-estimated. Code passing through LLVM spends a huge portion of its time in IRs other than LLVM IR, a lot of optimizations happen here. Even if one could perfectly copy all LLVM IR related parts, the result would at best be a third of a production quality compiler backend.
-
LLVM has many problems, but none of the biggest ones are at all related to its implementation language. That is not to say I believe the LLVM code base to be memory safe or very parallelizable or anything, in fact I don't. But the most frequent and the most serious issues are unrelated to that. Rewriting the same algorithms in a different language does nothing to fix miscompiles, improve compile times, categorically prevent certain missed optimizations, make backend work less manual and error prone, or help with any of the other issues that keep LLVM developers and users up at night.
-
LLVM is a moving target. It continually receives improvements, bug fixes, new features, refactorings, etc. so if one takes a snapshot of LLVM today and toils to rewrite that 1:1, the result will be a lot worse (on many axes) than LLVM is by the time the rewrite is finished.
And this is all without even going into estimated about who would have to work for how long, or how such a process could be structured. These are just fundamental issues that any project trying to replace LLVM must face.