Did more measurements on what exactly affects llvm-lines:
optimize, codegen-units and mir-opt do, but debug-assertions doesn't.
This commit is contained in:
parent
476dd40f63
commit
9a46f17fab
|
|
@ -21,7 +21,7 @@ Depending on what you're trying to measure, there are several different approach
|
||||||
eg. `cargo -Ztimings build`.
|
eg. `cargo -Ztimings build`.
|
||||||
You can use this flag on the compiler itself with `CARGOFLAGS="-Ztimings" ./x.py build`
|
You can use this flag on the compiler itself with `CARGOFLAGS="-Ztimings" ./x.py build`
|
||||||
|
|
||||||
## Optimizing rustc's self-compile-times with cargo-llvm-lines
|
## Optimizing rustc's bootstrap times with `cargo-llvm-lines`
|
||||||
|
|
||||||
Using [cargo-llvm-lines](https://github.com/dtolnay/cargo-llvm-lines) you can count the
|
Using [cargo-llvm-lines](https://github.com/dtolnay/cargo-llvm-lines) you can count the
|
||||||
number of lines of LLVM IR across all instantiations of a generic function.
|
number of lines of LLVM IR across all instantiations of a generic function.
|
||||||
|
|
@ -38,8 +38,8 @@ cargo install cargo-llvm-lines
|
||||||
RUSTFLAGS="--emit=llvm-ir" ./x.py build --stage 0 compiler/rustc
|
RUSTFLAGS="--emit=llvm-ir" ./x.py build --stage 0 compiler/rustc
|
||||||
|
|
||||||
# Single crate, eg. rustc_middle
|
# Single crate, eg. rustc_middle
|
||||||
cargo llvm-lines --files ./build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/debug/deps/rustc_middle* > llvm-lines-middle.txt
|
cargo llvm-lines --files ./build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/debug/deps/rustc_middle-a539a639bdab6513.ll > llvm-lines-middle.txt
|
||||||
# Whole compiler at once
|
# Specify all crates of the compiler. (Relies on the glob support of your shell.)
|
||||||
cargo llvm-lines --files ./build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/debug/deps/*.ll > llvm-lines.txt
|
cargo llvm-lines --files ./build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/debug/deps/*.ll > llvm-lines.txt
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
@ -72,7 +72,7 @@ you will be compiling rustc _a lot_.
|
||||||
I recommend changing a few settings in `config.toml` to make it bearable:
|
I recommend changing a few settings in `config.toml` to make it bearable:
|
||||||
```
|
```
|
||||||
[rust]
|
[rust]
|
||||||
# A debug build takes _a fourth_ as long on my machine,
|
# A debug build takes _a third_ as long on my machine,
|
||||||
# but compiling more than stage0 rustc becomes unbearably slow.
|
# but compiling more than stage0 rustc becomes unbearably slow.
|
||||||
optimize = false
|
optimize = false
|
||||||
|
|
||||||
|
|
@ -81,15 +81,14 @@ incremental = false
|
||||||
# We won't be running it, so no point in compiling debug checks.
|
# We won't be running it, so no point in compiling debug checks.
|
||||||
debug = false
|
debug = false
|
||||||
|
|
||||||
# Caution: This changes the output of llvm-lines.
|
# Using a single codegen unit gives less output, but is slower to compile.
|
||||||
# Using a single codegen unit gives more accurate output, but is slower to compile.
|
codegen-units = 0 # num_cpus
|
||||||
# Changing it to the number of cores on my machine increased the output
|
|
||||||
# from 3.5GB to 4.1GB and decreased compile times from 5½ min to 4 min.
|
|
||||||
codegen-units = 1
|
|
||||||
#codegen-units = 0 # num_cpus
|
|
||||||
```
|
```
|
||||||
|
|
||||||
What I'm still not sure about is if inlining in MIR optimizations affect llvm-lines.
|
The llvm-lines output is affected by several options.
|
||||||
The output with `-Zmir-opt-level=0` and `-Zmir-opt-level=1` is the same,
|
`optimize = false` increases it from 2.1GB to 3.5GB and `codegen-units = 0` to 4.1GB.
|
||||||
but it feels like that some functions that show up at the top should be to small
|
|
||||||
to have such a high impact. Inlining should only happens in LLVM though.
|
MIR optimizations have little impact. Compared to the default `RUSTFLAGS="-Zmir-opt-level=1"`,
|
||||||
|
level 0 adds 0.3GB and level 2 removes 0.2GB.
|
||||||
|
Inlining currently only happens in LLVM, but this might change in the future.
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue