Integration of the Cranelift backend with rustc

[bjorn3]

TL;DR

• Bring my Cranelift based codegen backend in tree using git subtree and gate PR's on it building.
• Extend the testing infrastructure to annotate tests as being specific for a single backend and
  annotate all LLVM specific tests.

Links and Details

This will first use git subtree to integrate the cg_clif repo. Then changes to bootstrap and
compiletest are needed to be able to build and test it. Next CI will need to gate PR's on cg_clif
building. CI will not run any tests for cg_clif. Finally all add a way to annotate tests as
requiring a specific backend and annotate all LLVM specific tests as such.

• The Cranelift backend: https://github.com/bjorn3/rustc_codegen_cranelift
• Design meeting proposal: Cranelift backend for rustc #257
• Pre-meeting details: https://hackmd.io/@bjorn3/HJL5ryFS8
• Meeting notes: Add meeting notes for the cranelift backend design meeting #269
• Complete discussion: https://zulip-archive.rust-lang.org/131828tcompiler/01241designmeeting20200403compilerteam257.html

Mentors or Reviewers

Maybe @Mark-Simulacrum for bootstrap changes?

[Mark-Simulacrum]

I think we should wait for clippy subtree to land (just to get the subtree infrastructure, documentation, etc. in place) -- I expect that to happen in the next few weeks. After that, I am willing to help or perhaps implement the build system changes necessary for integrating cranelift's codegen backend.

I suspect we will also want to line up a technical reviewer for compiler integration, though I think I can review that as well (and to some extent I don't know that there will be review required there beyond cleanup that occurs in an ongoing fashion).

[bjorn3]

I think we should wait for clippy subtree to land (just to get the subtree infrastructure, documentation, etc. in place) -- I expect that to happen in the next few weeks.

Agreed

After that, I am willing to help or perhaps implement the build system changes necessary for integrating cranelift's codegen backend.

I think this will involve a partial revert of rust-lang/rust#67077. Before that PR rustc_codegen_llvm was built as dylib after the rest of the compiler the same way that rustc_codegen_cranelift is currently built. That PR also removed the code to load a codegen backend dylib from the sysroot. I don't propose to revert to the state prior, but instead use the code to built rustc_codegen_cranelift as dylib.

[Mark-Simulacrum]

Hm, so I think that depends. If a build of cranelift is quick enough that we can enable it by default for developers (I hope it is), then I imagine we could statically link both and just have an if in the codegen backend selection.

Even if it isn't quick, I'd strongly prefer that we statically link it (behind a Cargo feature flag or so) just because that is likely to be much easier to get working on various systems, and then expose a -Zcodegen-cranelift flag to switch to it (or perhaps even a #![feature(...)] gate).

[bjorn3]

Statically linking it would require adding all necessary rustc crates to Cargo.toml rather than just getting them from the sysroot. This means that out of tree development of cg_clif would need those dependencies removed from Cargo.toml and added back when updating the subtree.

If a build of cranelift is quick enough that we can enable it by default for developers (I hope it is)

A full rebuild in release mode takes ~2min on my system.

and then expose a -Zcodegen-cranelift flag to switch to it

The way I proposed it, that would be -Zcodegen-backend=cranelift and then rustc would load the dylib from the sysroot.

(or perhaps even a #![feature(...)] gate)

The codegen backend is called immediately after the Session is created to extend the enabled cfg list with the enabled target features. This happens before the first file is parsed.

[spastorino]

Added to our compiler team meeting agenda, removing to-announce label.

[wesleywiser]

It's been about two months, how has the clippy subtree been working out? Does that still seem like the way to go for cg_clif?

[nikomatsakis]

cc @oli-obk @Manishearth -- I think it's been working out reasonably well, but I'm not sure if we have done the "rust repo -> clippy repo" style merges yet.

[Manishearth]

@nikomatsakis we've been using git subrepo, not git subtree. But it's been going okay i think. cc @flip1995

[flip1995]

@Manishearth we're using git subtree, but I wouldn't recommend to commit other things to that, since we are only able to use this, since we're using a version from this PR gitgitgadget/git#493, instead of the official git subtree version.

Once you gone through the subtree routine, I would say it is pretty nice, to just do a rustup with a few git commands and maybe a code format, instead of going through PRs to find the culprit.

[flip1995]

More about issues we have with git subtree here: rust-lang/rust-clippy#5565

In-depth documentation on how we use git subtree here: https://github.com/rust-lang/rust-clippy/blob/master/CONTRIBUTING.md#fixing-build-failures-caused-by-rust (note the note at the bottom of the section)

[Manishearth]

@flip1995 ugh i keep getting confused between subrepo and subtree. thanks

I think it's fine to use a forked subtree especially if fixes are incoming

[oli-obk]

@rustbot second