Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

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?


sort by: page size:

For Rust's LLVM fork, sure. But as Steve Klabnik noted in the first comment I linked, unmodified LLVM is supported.

In addition, later down in the comment chain:

cycloptic:

> Can't there be a build option to not use the LLVM submodule, and instead use the system LLVM?

steveklabnik:

> There is. We even test that it builds as part of our CI, to make sure it works, IIRC.

For a more concrete example, Fedora supports choosing between system and bundled LLVM when building Rust [0, 1].

[0]: https://news.ycombinator.com/item?id=26222190

[1]: https://src.fedoraproject.org/rpms/rust//blob/rawhide/f/rust...


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.

Reimplementing LLVM in Rust could make a big difference as well.

There are bugs in llvm mostly found by rust that are related to this. This will be another source of pressure to fix these bugs, which is good.

There is currently only one custom patch on top of LLVM[1] and it's just a performance one, not required for semantics.

[1]: https://github.com/rust-lang/llvm/commits/rust-llvm-2014-05-...


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.

Nope. You can use a stock LLVM if you want. Some tests might fail, since patches might not be in upstream yet.

It's not really something to resolve; it's just the usual situation with a big dependency.


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.

It appears you’re right, thank you! I’m very surprised there isn’t a llvm linker available, minus all the foundation kits that rust doesn’t need.

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.

Building llvm is the most memory intensive part of compiling Rust itself. You can, I believe, skip this and use pre-built llvm binaries.

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.

[1] https://gleam.run/

[2] https://github.com/Rust-GCC/gccrs


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...


Rust has contributed a lot to LLVM, see here for a recent summary: https://twitter.com/pcwalton/status/1366058442276790274
next

Legal | privacy