rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods #55627

sunfishcode · 2018-11-02T19:40:13Z

This PR is the continuation of #54012 and earlier PRs, in the grand plan of #45274 to allow for multiple codegen backends.

High-level summary: interpose a set of traits between Rust's codegen logic and the LLVM APIs, allowing another backend to implement the traits and share most of the codegen logic. These traits are currently somewhat LLVM-specific, but once this refactoring is in place, they can evolve to be more general.

See this README for a writeup on the current trait organization.

rust-highfive · 2018-11-02T19:40:26Z

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

sunfishcode · 2018-11-02T22:48:39Z

r? @eddyb

denismerigoux · 2018-11-03T08:53:04Z

Thanks for fixing the bug ! It was a silly mistake from my part...

@nikomatsakis

rustc_target: pass contexts by reference, not value. `LayoutOf` now takes `&self` instead of `self`, and so does every method generic over a context that implements `LayoutOf` and/or other traits, like `HasDataLayout`, `HasTyCtxt`, etc. Originally using by-value `Copy` types was relevant because `TyCtxt` was one of those types, but now `TyCtxt::layout_of` is separate from `LayoutOf`, and `TyCtxt` is not an often used layout context. Passing these context by reference is a lot nicer for miri, which has `self: &mut EvalContext`, and needed `f(&self)` (that is, creating `&&mut EvalContext` references) for layout purposes. Now, the `&mut EvalContext` can be passed to a function expecting `&C`, directly. This should help with #54012 / #55627 (to not need `where &'a T::Cx: LayoutOf` bounds). r? @nikomatsakis or @oli-obk or @nagisa cc @sunfishcode

eddyb

First batch of comments (my browser hates me already!)

eddyb · 2018-11-04T20:54:50Z

src/librustc_codegen_llvm/abi.rs

+    fn store_fn_arg(
+        &mut self,
+        ty: &ArgType<'tcx, Ty<'tcx>>,
+        idx: &mut usize, dst: PlaceRef<'tcx, <Self::CodegenCx as Backend<'ll>>::Value>


dst should probably be on its own line.

eddyb · 2018-11-04T20:57:06Z

src/librustc_codegen_llvm/abi.rs

+        bx: &mut Builder<'a, 'll, 'tcx, &'ll Value>,
+        idx: &mut usize,
+        dst: PlaceRef<'tcx, &'ll Value>
+    ) {


I think this is a LLVM-ism, does Cranelift support getting at the function params from a builder? What I'd do instead is also pass a slice of values, alongside the index.

eddyb · 2018-11-04T20:58:49Z

src/librustc_codegen_llvm/abi.rs

@@ -104,29 +106,29 @@ impl ArgAttributesExt for ArgAttributes {
 }

 pub trait LlvmType {
-    fn llvm_type(&self, cx: &CodegenCx<'ll, '_>) -> &'ll Type;
+    fn llvm_type(&self, cx: &CodegenCx<'ll, '_, &'ll Value>) -> &'ll Type;


Maybe have a crate-wide type-alias so that we can continue to write CodegenCx<'ll, '_> instead of CodegenCx<'ll, '_, &'ll Value> in rustc_codegen_llvm?

eddyb · 2018-11-04T21:13:23Z

src/librustc_codegen_llvm/abi.rs

+        &mut self,
+        ty: &FnType<'tcx, Ty<'tcx>>,
+        callsite: <Self::CodegenCx as Backend<'ll>>::Value
+    ) {


Hmm, I think it might be better if instead of the "apply attrs" LLVM-ism, the call/invoke methods of Builder took an FnType and internally called the LLVM-only apply_attrs_callsite.

eddyb · 2018-11-04T21:14:17Z

src/librustc_codegen_llvm/abi.rs

+    }
+    fn fn_type_of_instance(&self, instance: &Instance<'tcx>) -> FnType<'tcx, Ty<'tcx>> {
+        FnType::of_instance(&self, instance)
+    }


Do any of these depend on anything LLVM-specific? IMO these could be moved into rustc_codegen_ssa or even rustc itself!

eddyb · 2018-11-04T22:06:36Z