Stream: t-compiler/major changes

Topic: LLVM plugin support in Rust compiler-team#419

triagebot (Mar 17 2021 at 18:33, on Zulip):

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.

Josh Triplett (Mar 18 2021 at 03:01, on Zulip):

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.

Joshua Nelson (Mar 18 2021 at 03:55, on Zulip):

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

Joshua Nelson (Mar 18 2021 at 03:55, on Zulip):

adding this on nightly seems fine though

Josh Triplett (Mar 18 2021 at 06:24, on Zulip):

That wasn't my primary concern; I was already assuming that any such mechanism would have to be conditionally available.

Josh Triplett (Mar 18 2021 at 06:24, on Zulip):

My concern was that even after addressing that, it would be likely to break compatibility of the plugin interface regularly.

oli (Mar 18 2021 at 08:48, on Zulip):

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

bjorn3 (Mar 18 2021 at 08:52, on Zulip):

That did be -Cllvm-args. I am using it in cg_clif too.

nagisa (Mar 18 2021 at 09:59, on Zulip):

I think we can conditionally enable this only when building with system LLVM. that would make me significantly more comfortable with this.

cuviper (Mar 18 2021 at 16:37, on Zulip):

system-LLVM-only would work for me, but it does feel weird that a third-party build would be more featureful

bjorn3 (Mar 18 2021 at 16:50, on Zulip):

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

nagisa (Mar 18 2021 at 17:27, on Zulip):

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.

nagisa (Mar 18 2021 at 17:28, on Zulip):

(I say this as somebody who at some point tried to do something similar)

William Moses (Mar 19 2021 at 03:11, on Zulip):

@cuviper the rust ml group is interested in using 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.

Josh Triplett (Mar 19 2021 at 05:55, on Zulip):

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

Josh Triplett (Mar 19 2021 at 05:56, on Zulip):

Binaries and library. So that you always have a matching clang for cross-language LTO, or a library for bindgen.

nagisa (Mar 19 2021 at 12:55, on Zulip):

If we were to go that route, the first step would be to make the llvm backend its own distributable component.

nagisa (Mar 19 2021 at 12:56, on Zulip):

( would pave the way for this)

Last update: May 07 2021 at 07:30UTC