In clang we have
-Xclang -load -Xclang path/to/plugin.so, which could be used to load and run user-defined LLVM transformation / analysis passes on the generated IR before generating target code. As far as I know,
rustc does not have an equivalent way to load LLVM plugins similar to clang. Is there any plans on implementing this on
rustc? If this is a bad idea, why?
In clang we have
LLVM plugins are tied to a specific version of LLVM. Even if it becomes supported, it needs to stay unstable forever as we can update LLVM at any point and the same rustc version may even be linked against different LLVM versions when for example a distribution compiles it instead of using the official builds.
Speaking of distributions though, we would like a way to do this for stuff like annobin. As you say, the distro also controls the LLVM library in this case.
Annobin could be added to rustc itself I think. It seems useful enough.
So for now if I want to run my custom LLVM passes, I need to re-build a specific LLVM version with my passes present and then re-build rustc with this specific LLVM version?
Adding to this, neither the compiler interface, nor the compiler itself, should stablize even the existance of llvm in the toolchain (beyond the selection in
That's critically important, because even today LLVM is not the only backend for Rust. LLVM is the primary codegen backend for compiling Rust, but not the only one.
-C llvm-args=val already exists. I think it would be OK to add something like
-C llvm-plugin=path, ignored/error with other backends, but the point about LLVM versions remains.
Indeed. Not only that, other implementations may not support using llvm as a codegen backend (speaking as the author of such an implementation).
I presume that causes an error if the current code generator is not llvm. I wonder if that should be extended to
In rustc_codegen_cranelift I repurposed
-Cllvm-args for it's options, just like I repurposed
--emit llvm-ir to emit clif ir. I think renaming
-Ccodegen-args (with back compat support for
-Cllvm-args of course) would indeed be a good idea.
Even when using the original rustc, LLVM may not always be used in the future. (speaking as the author of an alternative backend for the official rustc compiler)