Go to file
bors 21be9da209 Auto merge of #95689 - lqd:self-profiler, r=wesleywiser
Allow self-profiler to only record potentially costly arguments when argument recording is turned on

As discussed [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Identifying.20proc-macro.20slowdowns/near/277304909) with `@wesleywiser,` I'd like to record proc-macro expansions in the self-profiler, with some detailed data (per-expansion spans for example, to follow #95473).

At the same time, I'd also like to avoid doing expensive things when tracking a generic activity's arguments, if they were not specifically opted into the event filter mask, to allow the self-profiler to be used in hotter contexts.

This PR tries to offer:
- a way to ensure a closure to record arguments will only be called in that situation, so that potentially costly arguments can still be recorded when needed. With the additional requirement that, if possible, it would offer a way to record non-owned data without adding many `generic_activity_with_arg_{...}`-style methods. This lead to the `generic_activity_with_arg_recorder` single entry-point, and the closure parameter would offer the new methods, able to be executed in a context where costly argument could be created without disturbing the profiled piece of code.
- some facilities/patterns allowing to record more rustc specific data in this situation, without making `rustc_data_structures`  where the self-profiler is defined, depend on other rustc crates (causing circular dependencies): in particular, spans. They are quite tricky to turn into strings (if the default `Debug` impl output does not match the context one needs them for), and since I'd also like to avoid the allocation there when arg recording is turned off today, that has turned into another flexibility requirement for the API in this PR (separating the span-specific recording into an extension trait). **edit**: I've removed this from the PR so that it's easier to review, and opened https://github.com/rust-lang/rust/pull/95739.
- allow for extensibility in the future: other ways to record arguments, or additional data attached to them could be added in the future (e.g. recording the argument's name as well as its data).

Some areas where I'd love feedback:
- the API and names: the `EventArgRecorder` and its method for example. As well as the verbosity that comes from the increased flexibility.
- if I should convert the existing `generic_activity_with_arg{s}` to just forward to `generic_activity_with_arg_recorder` + `recorder.record_arg` (or remove them altogether ? Probably not): I've used the new API in the simple case I could find of allocating for an arg that may not be recorded, and the rest don't seem costly.
- [x] whether this API should panic if no arguments were recorded by the user-provided closure (like this PR currently does: it seems like an error to use an API dedicated to record arguments but not call the methods to then do so) or if this should just record a generic activity without arguments ?
- whether the `record_arg` function should be `#[inline(always)]`, like the `generic_activity_*` functions ?

As mentioned, r? `@wesleywiser` following our recent discussion.
2022-04-16 11:43:28 +00:00
.github/workflows Merge commit '39683d8eb7a32a74bea96ecbf1e87675d3338506' into sync_cg_gcc-2022-03-26 2022-03-26 18:29:37 +01:00
build_sysroot Merge commit '39683d8eb7a32a74bea96ecbf1e87675d3338506' into sync_cg_gcc-2022-03-26 2022-03-26 18:29:37 +01:00
example Spellchecking some comments 2022-03-30 01:39:38 -04:00
patches Merge commit '39683d8eb7a32a74bea96ecbf1e87675d3338506' into sync_cg_gcc-2022-03-26 2022-03-26 18:29:37 +01:00
src Auto merge of #95689 - lqd:self-profiler, r=wesleywiser 2022-04-16 11:43:28 +00:00
tests Merge commit '39683d8eb7a32a74bea96ecbf1e87675d3338506' into sync_cg_gcc-2022-03-26 2022-03-26 18:29:37 +01:00
.gitignore Merge commit '39683d8eb7a32a74bea96ecbf1e87675d3338506' into sync_cg_gcc-2022-03-26 2022-03-26 18:29:37 +01:00
build.sh Merge commit '39683d8eb7a32a74bea96ecbf1e87675d3338506' into sync_cg_gcc-2022-03-26 2022-03-26 18:29:37 +01:00
Cargo.lock Merge commit '39683d8eb7a32a74bea96ecbf1e87675d3338506' into sync_cg_gcc-2022-03-26 2022-03-26 18:29:37 +01:00
cargo.sh Merge commit '39683d8eb7a32a74bea96ecbf1e87675d3338506' into sync_cg_gcc-2022-03-26 2022-03-26 18:29:37 +01:00
Cargo.toml Merge commit '1411a98352ba6bee8ba3b0131c9243e5db1e6a2e' into sync_cg_clif-2021-12-31 2021-12-31 16:26:32 +01:00
clean_all.sh Initial commit 2021-08-12 21:46:50 -04:00
config.sh Update references to -Z symbol-mangling-version to use -C 2022-01-01 15:53:11 -08:00
LICENSE-APACHE Initial commit 2021-08-12 21:46:50 -04:00
LICENSE-MIT Initial commit 2021-08-12 21:46:50 -04:00
prepare_build.sh Merge commit '39683d8eb7a32a74bea96ecbf1e87675d3338506' into sync_cg_gcc-2022-03-26 2022-03-26 18:29:37 +01:00
prepare.sh Initial commit 2021-08-12 21:46:50 -04:00
Readme.md Spellchecking some comments 2022-03-30 01:39:38 -04:00
rust-toolchain Merge commit '39683d8eb7a32a74bea96ecbf1e87675d3338506' into sync_cg_gcc-2022-03-26 2022-03-26 18:29:37 +01:00
rustup.sh Spellchecking compiler code 2022-03-30 01:42:10 -04:00
test.sh Merge commit '39683d8eb7a32a74bea96ecbf1e87675d3338506' into sync_cg_gcc-2022-03-26 2022-03-26 18:29:37 +01:00

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. The patches in this repository need to be applied. (Those patches should work when applied on master, but in case it doesn't work, they are known to work when applied on 079c23cfe079f203d5df83fea8e92a60c7d7e878.) You can also use my fork of gcc which already includes these patches.

Put the path to your custom build of libgccjit in the file gcc_path.

$ git clone https://github.com/rust-lang/rustc_codegen_gcc.git
$ cd rustc_codegen_gcc
$ git clone https://github.com/llvm/llvm-project llvm --depth 1 --single-branch
$ export RUST_COMPILER_RT_ROOT="$PWD/llvm/compiler-rt"
$ ./prepare_build.sh # download and patch sysroot src
$ ./build.sh --release

To run the tests:

$ ./prepare.sh # download and patch sysroot src and install hyperfine for benchmarking
$ ./test.sh --release

Usage

$cg_gccjit_dir is the directory you cloned this repo into in the following instructions.

Cargo

$ CHANNEL="release" $cg_gccjit_dir/cargo.sh run

If you compiled cg_gccjit in debug mode (aka you didn't pass --release to ./test.sh) you should use CHANNEL="debug" instead or omit CHANNEL="release" completely.

Rustc

You should prefer using the Cargo method.

$ rustc +$(cat $cg_gccjit_dir/rust-toolchain) -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

Debugging

Sometimes, libgccjit will crash and output an error like this:

during RTL pass: expand
libgccjit.so: error: in expmed_mode_index, at expmed.h:249
0x7f0da2e61a35 expmed_mode_index
	../../../gcc/gcc/expmed.h:249
0x7f0da2e61aa4 expmed_op_cost_ptr
	../../../gcc/gcc/expmed.h:271
0x7f0da2e620dc sdiv_cost_ptr
	../../../gcc/gcc/expmed.h:540
0x7f0da2e62129 sdiv_cost
	../../../gcc/gcc/expmed.h:558
0x7f0da2e73c12 expand_divmod(int, tree_code, machine_mode, rtx_def*, rtx_def*, rtx_def*, int)
	../../../gcc/gcc/expmed.c:4335
0x7f0da2ea1423 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier)
	../../../gcc/gcc/expr.c:9240
0x7f0da2cd1a1e expand_gimple_stmt_1
	../../../gcc/gcc/cfgexpand.c:3796
0x7f0da2cd1c30 expand_gimple_stmt
	../../../gcc/gcc/cfgexpand.c:3857
0x7f0da2cd90a9 expand_gimple_basic_block
	../../../gcc/gcc/cfgexpand.c:5898
0x7f0da2cdade8 execute
	../../../gcc/gcc/cfgexpand.c:6582

To see the code which causes this error, call the following function:

gcc_jit_context_dump_to_file(ctxt, "/tmp/output.c", 1 /* update_locations */)

This will create a C-like file and add the locations into the IR pointing to this C file. Then, rerun the program and it will output the location in the second line:

libgccjit.so: /tmp/something.c:61322:0: error: in expmed_mode_index, at expmed.h:249

Or add a breakpoint to add_error in gdb and print the line number using:

p loc->m_line
p loc->m_filename->m_buffer

To print a debug representation of a tree:

debug_tree(expr);

To get the rustc command to run in gdb, add the --verbose flag to cargo build.

How to use a custom-build rustc

  • Build the stage2 compiler (rustup toolchain link debug-current build/x86_64-unknown-linux-gnu/stage2).
  • Clean and rebuild the codegen with debug-current in the file rust-toolchain.

How to build a cross-compiling libgccjit

Building libgccjit

  • Follow these instructions: https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/ with the following changes:
  • Configure gcc with ../gcc/configure --enable-host-shared --disable-multilib --enable-languages=c,jit,c++ --disable-bootstrap --enable-checking=release --prefix=/opt/m68k-gcc/ --target=m68k-linux --without-headers.
  • Some shells, like fish, don't define the environment variable $MACHTYPE.
  • Add CFLAGS="-Wno-error=attributes -g -O2" at the end of the configure command for building glibc (CFLAGS="-Wno-error=attributes -Wno-error=array-parameter -Wno-error=stringop-overflow -Wno-error=array-bounds -g -O2" for glibc 2.31, which is useful for Debian).

Configuring rustc_codegen_gcc

  • Set TARGET_TRIPLE="m68k-unknown-linux-gnu" in config.sh.
  • Since rustc doesn't support this architecture yet, set it back to TARGET_TRIPLE="mips-unknown-linux-gnu" (or another target having the same attributes). Alternatively, create a target specification file (note that the arch specified in this file must be supported by the rust compiler).
  • Set linker='-Clinker=m68k-linux-gcc'.
  • Set the path to the cross-compiling libgccjit in gcc_path.
  • Disable the 128-bit integer types if the target doesn't support them by using let i128_type = context.new_type::<i64>(); in context.rs (same for u128_type).
  • Comment the line: context.add_command_line_option("-masm=intel"); in src/base.rs.
  • (might not be necessary) Disable the compilation of libstd.so (and possibly libcore.so?).