On Dec 8, 2023, at 8:19 AM, Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx> wrote: > > If LLVM folks think LLVM-wise nothing will break, then we are happy to > go ahead with that (since it also solves the performance side), but it > would be nice to know if it will always be OK to build like that, i.e. > I think Andreas actually tried it and it seemed to work and boot, but > the worry is whether there is something subtle that could have bad > codegen in the future. One potential issue is incompatibility between the LLVM versions used by rustc, Clang, and LLD. At minimum, whichever tool is reading bitcode (LLD in my example) should have an LLVM version >= that of the tools producing bitcode, since newer LLVM versions can read older bitcode but not vice versa. But ideally the tools would all just be linked against the same copy of LLVM. If you’re getting your tools from a distro, then that may already be true for you. But if you’re using upstream rustc binaries, those are built against a custom branch of LLVM, which is based on upstream release versions but adds a handful of patches [1]; by policy, those patches can include cherry-picks of miscompilation fixes that are upstream but haven’t made it into a release yet [2]. Upstream rustc binaries are accompanied by a copy of LLD linked against the same LLVM library, named rust-lld, but there’s no corresponding copy of Clang [3]. I’d say that agreement between rustc and LLD is the most important thing, but it would be nice if they'd make a matching Clang available through rustup. [1] https://github.com/llvm/llvm-project/compare/release/17.x...rust-lang:llvm-project:rustc/17.0-2023-09-19 [2] https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html#bugfix-updates [3] https://github.com/rust-lang/rust/issues/56371
