Can't there be a build option to not use the LLVM submodule, and instead use the system LLVM? Assuming there are tests for these LLVM bugs, and assuming the patches are indeed being merged, wouldn't a CI be able to catch when it is safe for downstream users that want to use upstream LLVM to update their Rust installation?
In general I would be very curious to know more about the bugs, etc in LLVM which would benefit Rust. I'm of the impression that there are many because LLVM is so over-fitted to the C++ ecosystem, but I don't know much about them in particular.
We generally try to upstream our patches, and they've been generally accepted. IIRC, our current fork is very close to LLVM head. We also do support building with stock LLVM, though it may have bugs for the stuff that wasn't patched at the time that release was made, of course.
I really hope this type of infrastructure gets moved into LLVM itself, and people start adding more benchmarks for all the frontends, and somehow integrating this into the CI infrastructure, to be able to block merging PRs on changes that accidentally impact LLVM's performance, like is currently the case for rustc.
But I guess the LLVM project should probably start by making code-reviews mandatory, gating PRs on passing tests so that master doesn't get broken all the time, etc. I really hate it when I update my LLVM locally from git master, and it won't even build because somebody pushed to master without even testing that their changes compile...
For Rust, I hope Cranelift really takes off someday, and we can start to completely ditch LLVM and make it opt-in, only for those cases in which you are willing to trade-off huge compile-times for that last 1% run-time reduction.
I think we might be talking past each other, because I never claimed otherwise. My point was that LLVM-IR is not a solution to anything becase LLVM-IR would have the same problem, LLVM has a separate release schedule from gcc. I think using the MIR is the best alternative which does not require writing and maintaining a separate frontend from rustc.
As proven by D, OCaml, F#, Delphi, Ada, C++23 (with modules, VC++/clang 18), it is a matter of toolchain.
What we need is a Rust interpreter, or having something like Cranelift properly integrated, to only depend on LLVM when doing release builds on the CI/CD.
Eh, it’s not as one-sided as that. GCC has a larger number of targets, but LLVM supports several newer targets that GCC doesn’t, like WebAssembly and eBPF (although the latter is coming in GCC 10). But it would certainly be nice for Rust to support both sets of targets.
My point is that a) half of the work doesn't have to happen because of LLVM's back-/front-end split, and b) if these are architectures that people care about keeping around and investing in, the benefits of adding LLVM support will go beyond just Rust
LLVM is used for optimizations in Rust. LLVM is more than just a nice way to target multiple backends, it's a very sophisticated set of building blocks for compilers.
LLVM is written in C++, so any change of Rust compiler that requires changes in the backend requires C++ knowledge, and naturally dependency on a C++ compiler to get the rust compiler binary.
I was wondering the same thing. It's not as though LLVM is some niche project that only Rust is using; it's the backend for a large number of compilers, and I imagine this will continue to be the case moving forward. There are now even languages that are written in languages that use LLVM for their backend, like gleam [1].
I think, ideally, there would be a concerted effort to extend LLVM compatibility to those platforms. But I don't think it's unreasonable to assume that there simply won't be--I sometimes run into problems on aarch64, and most of these are far more niche than that. As the article mentioned, it seems likely that eventually the ability for certain platforms for get support on new compilers will be a make-or-break for their ability to stay current with upgrades for a lot of the more fundamental packages.
Alternatively, I guess, there could be effort to get a new gcc-backend for more langauges; I believe there's an ongoing effort for Rust[2], but who knows down the line what that might look like. Eventually, this will probably need to come to a head.
Interesting, what do you think makes is encumbered by LLVM?
I thought that sqeezing MIR in the middle Rust could get both Rust-specific transformations and then benefits from the LLVM generic code optimizations...
reply