A new proposal has been announced: LLVM plugin support in Rust #419. It will be announced at the next meeting to try and draw attention to it, but usually MCPs are not discussed during triage meetings. If you think this would benefit from discussion amongst the team, consider proposing a design meeting.
This seems reasonable. I think it'd need to stay on nightly for a long time, and might or might not be possible to stabilize, since I don't think we'd be able to offer much in the way of stability guarantees about it.
I don't think we should stabilize that rustc uses an LLVM backend at all; that break cg_clif and prevents other implementations from using a backend other than LLVM
adding this on nightly seems fine though
That wasn't my primary concern; I was already assuming that any such mechanism would have to be conditionally available.
My concern was that even after addressing that, it would be likely to break compatibility of the plugin interface regularly.
Maybe we could add a generic way to send stringly typed configuration to backends? It would then be the backend's job to error on invalid configuration values
That did be
-Cllvm-args. I am using it in cg_clif too.
I think we can conditionally enable this only when building with system LLVM. that would make me significantly more comfortable with this.
system-LLVM-only would work for me, but it does feel weird that a third-party build would be more featureful
Could we get a list of all use cases for LLVM plugins? The only I know of currently is annobin, for which I could see value in integrating it in rustc proper. For example an LLVM plugin wouldn't be able to get the list of source files used for the build, while rustc can. It also has overlap with https://github.com/Shnatsel/rust-audit.
I really want to avoid people relying on us shipping a LLVM as a DSO in any particular shape or form. Were a profilic consumer of rustc (for sake of example lets say Firefox) start relying on a particular version of LLVM we ship, upgrading LLVM would also become significantly more painful – we'd be breaking or need to coordinate whatever upgrades.
(I say this as somebody who at some point tried to do something similar)
@cuviper the rust ml group is interested in using Enzyme (https://github.com/wsmoses/Enzyme) to provide automatic differentiation capabilities for certain codes [obvious bias as both author of this MCP and Enzyme].
Regarding LLVM version nonsense, I would argue that only plugins built for the precise version of LLVM rustc is built agains should be allowed. We might even be able to enforce this if we only allowed plugins built by a specific Rust build process that builds it against the same version of LLVM.
@nagisa So, I wouldn't want to make it dependent on LLVM version, but I would really like to ship the LLVM associated with a rust build in a sysroot crate.
Binaries and library. So that you always have a matching clang for cross-language LTO, or a library for bindgen.
If we were to go that route, the first step would be to make the llvm backend its own distributable component.
(https://github.com/rust-lang/rust/pull/81746 would pave the way for this)