0d7b2fb797
Stabilize the size of incr comp object file names
The current implementation does not produce stable-length paths, and we create the paths in a way that makes our allocation behavior is nondeterministic. I think `@eddyb` fixed a number of other cases like this in the past, and this PR fixes another one. Whether that actually matters I have no idea, but we still have bimodal behavior in rustc-perf and the non-uniformity in `find` and `ls` was bothering me.
I've also removed the truncation of the mangled CGU names. Before this PR incr comp paths look like this:
```
target/debug/incremental/scratch-38izrrq90cex7/s-gux6gz0ow8-1ph76gg-ewe1xj434l26w9up5bedsojpd/261xgo1oqnd90ry5.o
```
And after, they look like this:
```
target/debug/incremental/scratch-035omutqbfkbw/s-gux6borni0-16r3v1j-6n64tmwqzchtgqzwwim5amuga/55v2re42sztc8je9bva6g8ft3.o
```
On the one hand, I'm sure this will break some people's builds because they're on Windows and only a few bytes from the path length limit. But if we're that seriously worried about the length of our file names, I have some other ideas on how to make them smaller. And last time I deleted some hash truncations from the compiler, there was a huge drop in the number if incremental compilation ICEs that were reported: https://github.com/rust-lang/rust/pull/110367https://github.com/rust-lang/rust/pull/110367
---
Upon further reading, this PR actually fixes a bug. This comment says the CGU names are supposed to be a fixed-length hash, and before this PR they aren't:
|
||
---|---|---|
.. | ||
.github/workflows | ||
build_sysroot | ||
build_system | ||
deps | ||
doc | ||
example | ||
patches | ||
src | ||
tests | ||
tools | ||
.gitignore | ||
.ignore | ||
.rustfmt.toml | ||
build.rs | ||
Cargo.lock | ||
Cargo.toml | ||
config.example.toml | ||
libgccjit.version | ||
LICENSE-APACHE | ||
LICENSE-MIT | ||
messages.ftl | ||
Readme.md | ||
rust-toolchain | ||
y.sh |
WIP libgccjit codegen backend for rust
This is a GCC codegen for rustc, which means it can be loaded by the existing rustc frontend, but benefits from GCC: more architectures are supported and GCC's optimizations are used.
Despite its name, libgccjit can be used for ahead-of-time compilation, as is used here.
Motivation
The primary goal of this project is to be able to compile Rust code on platforms unsupported by LLVM. A secondary goal is to check if using the gcc backend will provide any run-time speed improvement for the programs compiled using rustc.
Building
This requires a patched libgccjit in order to work. You need to use my fork of gcc which already includes these patches.
$ cp config.example.toml config.toml
If don't need to test GCC patches you wrote in our GCC fork, then the default configuration should
be all you need. You can update the rustc_codegen_gcc
without worrying about GCC.
Building with your own GCC version
If you wrote a patch for GCC and want to test it without this backend, you will need to do a few more things.
To build it (most of these instructions come from here, so don't hesitate to take a look there if you encounter an issue):
$ git clone https://github.com/antoyo/gcc
$ sudo apt install flex libmpfr-dev libgmp-dev libmpc3 libmpc-dev
$ mkdir gcc-build gcc-install
$ cd gcc-build
$ ../gcc/configure \
--enable-host-shared \
--enable-languages=jit \
--enable-checking=release \ # it enables extra checks which allow to find bugs
--disable-bootstrap \
--disable-multilib \
--prefix=$(pwd)/../gcc-install
$ make -j4 # You can replace `4` with another number depending on how many cores you have.
If you want to run libgccjit tests, you will need to also enable the C++ language in the configure
:
--enable-languages=jit,c++
Then to run libgccjit tests:
$ cd gcc # from the `gcc-build` folder
$ make check-jit
# To run one specific test:
$ make check-jit RUNTESTFLAGS="-v -v -v jit.exp=jit.dg/test-asm.cc"
Put the path to your custom build of libgccjit in the file config.toml
.
You now need to set the gcc-path
value in config.toml
with the result of this command:
$ dirname $(readlink -f `find . -name libgccjit.so`)
and to comment the download-gccjit
setting:
gcc-path = "[MY PATH]"
# download-gccjit = true
Then you can run commands like this:
$ ./y.sh prepare # download and patch sysroot src and install hyperfine for benchmarking
$ ./y.sh build --release
To run the tests:
$ ./y.sh test --release
Usage
$CG_GCCJIT_DIR
is the directory you cloned this repo into in the following instructions:
export CG_GCCJIT_DIR=[the full path to rustc_codegen_gcc]
Cargo
$ CHANNEL="release" $CG_GCCJIT_DIR/y.sh cargo run
If you compiled cg_gccjit in debug mode (aka you didn't pass --release
to ./y.sh test
) you should use CHANNEL="debug"
instead or omit CHANNEL="release"
completely.
LTO
To use LTO, you need to set the variable FAT_LTO=1
and EMBED_LTO_BITCODE=1
in addition to setting lto = "fat"
in the Cargo.toml
.
Don't set FAT_LTO
when compiling the sysroot, though: only set EMBED_LTO_BITCODE=1
.
Failing to set EMBED_LTO_BITCODE
will give you the following error:
error: failed to copy bitcode to object file: No such file or directory (os error 2)
Rustc
You should prefer using the Cargo method.
$ LIBRARY_PATH="[gcc-path value]" LD_LIBRARY_PATH="[gcc-path value]" rustc +$(cat $CG_GCCJIT_DIR/rust-toolchain | grep 'channel' | cut -d '=' -f 2 | sed 's/"//g' | sed 's/ //g') -Cpanic=abort -Zcodegen-backend=$CG_GCCJIT_DIR/target/release/librustc_codegen_gcc.so --sysroot $CG_GCCJIT_DIR/build_sysroot/sysroot my_crate.rs
Env vars
- CG_GCCJIT_INCR_CACHE_DISABLED
- Don't cache object files in the incremental cache. Useful during development of cg_gccjit to make it possible to use incremental mode for all analyses performed by rustc without caching object files when their content should have been changed by a change to cg_gccjit.
- CG_GCCJIT_DISPLAY_CG_TIME
- Display the time it took to perform codegen for a crate
- CG_RUSTFLAGS
- Send additional flags to rustc. Can be used to build the sysroot without unwinding by setting `CG_RUSTFLAGS=-Cpanic=abort`.
- CG_GCCJIT_DUMP_TO_FILE
- Dump a C-like representation to /tmp/gccjit_dumps and enable debug info in order to debug this C-like representation.
Extra documentation
More specific documentation is available in the doc
folder:
- Common errors
- Debugging GCC LTO
- Debugging libgccjit
- Git subtree sync
- List of useful commands
- Send a patch to GCC
Licensing
While this crate is licensed under a dual Apache/MIT license, it links to libgccjit
which is under the GPLv3+ and thus, the resulting toolchain (rustc + GCC codegen) will need to be released under the GPL license.
However, programs compiled with rustc_codegen_gcc
do not need to be released under a GPL license.