79a1bddaf3
Add `Ord::cmp` for primitives as a `BinOp` in MIR
Update: most of this OP was written months ago. See https://github.com/rust-lang/rust/pull/118310#issuecomment-2016940014 below for where we got to recently that made it ready for review.
---
There are dozens of reasonable ways to implement `Ord::cmp` for integers using comparison, bit-ops, and branches. Those differences are irrelevant at the rust level, however, so we can make things better by adding `BinOp::Cmp` at the MIR level:
1. Exactly how to implement it is left up to the backends, so LLVM can use whatever pattern its optimizer best recognizes and cranelift can use whichever pattern codegens the fastest.
2. By not inlining those details for every use of `cmp`, we drastically reduce the amount of MIR generated for `derive`d `PartialOrd`, while also making it more amenable to MIR-level optimizations.
Having extremely careful `if` ordering to μoptimize resource usage on broadwell (#63767) is great, but it really feels to me like libcore is the wrong place to put that logic. Similarly, using subtraction [tricks](https://graphics.stanford.edu/~seander/bithacks.html#CopyIntegerSign) (#105840) is arguably even nicer, but depends on the optimizer understanding it (https://github.com/llvm/llvm-project/issues/73417) to be practical. Or maybe [bitor is better than add](https://discourse.llvm.org/t/representing-in-ir/67369/2?u=scottmcm)? But maybe only on a future version that [has `or disjoint` support](https://discourse.llvm.org/t/rfc-add-or-disjoint-flag/75036?u=scottmcm)? And just because one of those forms happens to be good for LLVM, there's no guarantee that it'd be the same form that GCC or Cranelift would rather see -- especially given their very different optimizers. Not to mention that if LLVM gets a spaceship intrinsic -- [which it should](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Suboptimal.20inlining.20in.20std.20function.20.60binary_search.60/near/404250586) -- we'll need at least a rustc intrinsic to be able to call it.
As for simplifying it in Rust, we now regularly inline `{integer}::partial_cmp`, but it's quite a large amount of IR. The best way to see that is with
|
||
|---|---|---|
| .github | ||
| .vscode | ||
| build_system | ||
| docs | ||
| example | ||
| patches | ||
| scripts | ||
| src | ||
| .cirrus.yml | ||
| .gitattributes | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| clean_all.sh | ||
| config.txt | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| Readme.md | ||
| rust-toolchain | ||
| rustfmt.toml | ||
| test.sh | ||
| y.cmd | ||
| y.ps1 | ||
| y.sh | ||
Cranelift codegen backend for rust
The goal of this project is to create an alternative codegen backend for the rust compiler based on Cranelift. This has the potential to improve compilation times in debug mode. If your project doesn't use any of the things listed under "Not yet supported", it should work fine. If not please open an issue.
Download using Rustup
The Cranelift codegen backend is distributed in nightly builds on Linux and x86_64 macOS. If you want to install it using Rustup, you can do that by running:
$ rustup component add rustc-codegen-cranelift-preview --toolchain nightly
Once it is installed, you can enable it with one of the following approaches:
CARGO_PROFILE_DEV_CODEGEN_BACKEND=cranelift cargo +nightly build -Zcodegen-backendRUSTFLAGS="-Zcodegen-backend=cranelift" cargo +nightly build- Add the following to
.cargo/config.toml:[unstable] codegen-backend = true [profile.dev] codegen-backend = "cranelift" - Add the following to
Cargo.toml:# This line needs to come before anything else in Cargo.toml cargo-features = ["codegen-backend"] [profile.dev] codegen-backend = "cranelift"
Precompiled builds
You can also download a pre-built version from the releases page.
Extract the dist directory in the archive anywhere you want.
If you want to use cargo clif build instead of having to specify the full path to the cargo-clif executable, you can add the bin subdirectory of the extracted dist directory to your PATH.
(tutorial for Windows, and for Linux/MacOS).
Building and testing
If you want to build the backend manually, you can download it from GitHub and build it yourself:
$ git clone https://github.com/rust-lang/rustc_codegen_cranelift
$ cd rustc_codegen_cranelift
$ ./y.sh prepare
$ ./y.sh build
To run the test suite replace the last command with:
$ ./test.sh
For more docs on how to build and test see build_system/usage.txt or the help message of ./y.sh.
Platform support
| OS \ architecture | x86_64 | AArch64 | Riscv64 | s390x (System-Z) |
|---|---|---|---|---|
| Linux | ✅ | ✅ | ✅1 | ✅1 |
| FreeBSD | ✅1 | ❓ | ❓ | ❓ |
| AIX | ❌2 | N/A | N/A | ❌2 |
| Other unixes | ❓ | ❓ | ❓ | ❓ |
| macOS | ✅ | ❌3 | N/A | N/A |
| Windows | ✅1 | ❌ | N/A | N/A |
✅: Fully supported and tested ❓: Maybe supported, not tested ❌: Not supported at all
Not all targets are available as rustup component for nightly. See notes in the platform support matrix.
Usage
rustc_codegen_cranelift can be used as a near-drop-in replacement for cargo build or cargo run for existing projects.
Assuming $cg_clif_dir is the directory you cloned this repo into and you followed the instructions (y.sh prepare and y.sh build or test.sh).
In the directory with your project (where you can do the usual cargo build), run:
$ $cg_clif_dir/dist/cargo-clif build
This will build your project with rustc_codegen_cranelift instead of the usual LLVM backend.
For additional ways to use rustc_codegen_cranelift like the JIT mode see usage.md.
Building and testing with changes in rustc code
This is useful when changing code in rustc_codegen_cranelift as part of changing main Rust repository.
This can happen, for example, when you are implementing a new compiler intrinsic.
Instruction below uses $RustCheckoutDir as substitute for any folder where you cloned Rust repository.
You need to do this steps to successfully compile and use the cranelift backend with your changes in rustc code:
cd $RustCheckoutDir- Run
python x.py setupand choose option for compiler (b). - Build compiler and necessary tools:
python x.py build --stage=2 compiler library/std src/tools/rustdoc src/tools/rustfmt- (Optional) You can also build cargo by adding
src/tools/cargoto previous command.
- (Optional) You can also build cargo by adding
- Copy cargo from a nightly toolchain:
cp $(rustup +nightly which cargo) ./build/host/stage2/bin/cargo. Note that you would need to do this every time you rebuiltrustrepository. - Link your new
rustcto toolchain:rustup toolchain link stage2 ./build/host/stage2/. - (Windows only) compile the build system:
rustc +stage2 -O build_system/main.rs -o y.exe. - You need to prefix every
./y.sh(oryif you builtbuild_system/main.rsasy) command byrustup run stage2to make cg_clif use your local changes in rustc.
rustup run stage2 ./y.sh preparerustup run stage2 ./y.sh build- (Optional) run tests:
rustup run stage2 ./y.sh test
- Now you can use your cg_clif build to compile other Rust programs, e.g. you can open any Rust crate and run commands like
$RustCheckoutDir/compiler/rustc_codegen_cranelift/dist/cargo-clif build --release.
You can also set rust-analyzer.rustc.source to your rust workspace to get rust-analyzer to understand your changes.
Not yet supported
- SIMD (tracked here,
std::simdfully works,std::archis partially supported) - Unwinding on panics (no cranelift support,
-Cpanic=abortis enabled by default)
License
Licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you shall be dual licensed as above, without any additional terms or conditions.