95182bb2cc
### Overview
This commit begins the implementation work for RFC 2945. For more
information, see the rendered RFC [1] and tracking issue [2].
A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
and `Thiscall` variants, marking whether unwinding across FFI
boundaries is acceptable. The cases where each of these variants'
`unwind` member is true correspond with the `C-unwind`,
`system-unwind`, `stdcall-unwind`, and `thiscall-unwind` ABI strings
introduced in RFC 2945 [3].
### Feature Gate and Unstable Book
This commit adds a `c_unwind` feature gate for the new ABI strings.
Tests for this feature gate are included in `src/test/ui/c-unwind/`,
which ensure that this feature gate works correctly for each of the
new ABIs.
A new language features entry in the unstable book is added as well.
### Further Work To Be Done
This commit does not proceed to implement the new unwinding ABIs,
and is intentionally scoped specifically to *defining* the ABIs and
their feature flag.
### One Note on Test Churn
This will lead to some test churn, in re-blessing hash tests, as the
deleted comment in `src/librustc_target/spec/abi.rs` mentioned,
because we can no longer guarantee the ordering of the `Abi`
variants.
While this is a downside, this decision was made bearing in mind
that RFC 2945 states the following, in the "Other `unwind` Strings"
section [3]:
> More unwind variants of existing ABI strings may be introduced,
> with the same semantics, without an additional RFC.
Adding a new variant for each of these cases, rather than specifying
a payload for a given ABI, would quickly become untenable, and make
working with the `Abi` enum prone to mistakes.
This approach encodes the unwinding information *into* a given ABI,
to account for the future possibility of other `-unwind` ABI
strings.
### Ignore Directives
`ignore-*` directives are used in two of our `*-unwind` ABI test
cases.
Specifically, the `stdcall-unwind` and `thiscall-unwind` test cases
ignore architectures that do not support `stdcall` and
`thiscall`, respectively.
These directives are cribbed from
`src/test/ui/c-variadic/variadic-ffi-1.rs` for `stdcall`, and
`src/test/ui/extern/extern-thiscall.rs` for `thiscall`.
This would otherwise fail on some targets, see:
|
||
---|---|---|
.github/workflows | ||
.vscode | ||
build_sysroot | ||
crate_patches | ||
docs | ||
example | ||
patches | ||
scripts | ||
src | ||
.cirrus.yml | ||
.gitattributes | ||
.gitignore | ||
build.sh | ||
Cargo.lock | ||
Cargo.toml | ||
clean_all.sh | ||
LICENSE-APACHE | ||
LICENSE-MIT | ||
prepare.sh | ||
Readme.md | ||
rust-toolchain | ||
rustfmt.toml | ||
test.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.
Building and testing
$ git clone https://github.com/bjorn3/rustc_codegen_cranelift.git
$ cd rustc_codegen_cranelift
$ ./prepare.sh # download and patch sysroot src and install hyperfine for benchmarking
$ ./build.sh
To run the test suite replace the last command with:
$ ./test.sh
This will implicitly build cg_clif too. Both build.sh
and test.sh
accept a --debug
argument to
build in debug mode.
Alternatively you can download a pre built version from GHA. It is listed in the artifacts section of workflow runs. Unfortunately due to GHA restrictions you need to be logged in to access it.
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 (prepare.sh
and build.sh
or test.sh
).
Cargo
In the directory with your project (where you can do the usual cargo build
), run:
$ $cg_clif_dir/build/cargo.sh run
This should build and run your project with rustc_codegen_cranelift instead of the usual LLVM backend.
Rustc
You should prefer using the Cargo method.
$ $cg_clif_dir/build/bin/cg_clif my_crate.rs
Jit mode
In jit mode cg_clif will immediately execute your code without creating an executable file.
This requires all dependencies to be available as dynamic library. The jit mode will probably need cargo integration to make this possible.
$ $cg_clif_dir/build/cargo.sh jit
or
$ $cg_clif_dir/build/bin/cg_clif -Cllvm-args=mode=jit -Cprefer-dynamic my_crate.rs
There is also an experimental lazy jit mode. In this mode functions are only compiled once they are first called. It currently does not work with multi-threaded programs. When a not yet compiled function is called from another thread than the main thread, you will get an ICE.
$ $cg_clif_dir/build/cargo.sh lazy-jit
Shell
These are a few functions that allow you to easily run rust code from the shell using cg_clif as jit.
function jit_naked() {
echo "$@" | $cg_clif_dir/build/bin/cg_clif - -Cllvm-args=mode=jit -Cprefer-dynamic
}
function jit() {
jit_naked "fn main() { $@ }"
}
function jit_calc() {
jit 'println!("0x{:x}", ' $@ ');';
}
Env vars
Not yet supported
- Inline assembly (no cranelift support)
- On Linux there is support for invoking an external assembler for
global_asm!
andasm!
.llvm_asm!
will remain unimplemented forever.asm!
doesn't yet support reg classes. You have to specify specific registers instead.
- On Linux there is support for invoking an external assembler for
- SIMD (tracked here, some basic things work)