This is an additional 17% improvement on ./y.rs compile --sysroot none
Benchmark 1: ./y_before.bin build --sysroot none
Time (mean ± σ): 1.533 s ± 0.022 s [User: 1.411 s, System: 0.471 s]
Range (min … max): 1.517 s … 1.589 s 10 runs
Benchmark 2: ./y_after.bin build --sysroot none
Time (mean ± σ): 1.311 s ± 0.020 s [User: 1.232 s, System: 0.428 s]
Range (min … max): 1.298 s … 1.366 s 10 runs
Summary
'./y_after.bin build --sysroot none' ran
1.17 ± 0.02 times faster than './y_before.bin build --sysroot none'
By avoiding some redundant rustc calls and stripping debuginfo for
wrappers. ./y.rs build --sysroot none now runs 44% faster.
Benchmark 1: ./y_before.bin build --sysroot none
Time (mean ± σ): 2.200 s ± 0.038 s [User: 2.140 s, System: 0.653 s]
Range (min … max): 2.171 s … 2.303 s 10 runs
Benchmark 2: ./y_after.bin build --sysroot none
Time (mean ± σ): 1.528 s ± 0.020 s [User: 1.388 s, System: 0.490 s]
Range (min … max): 1.508 s … 1.580 s 10 runs
Summary
'./y_after.bin build --sysroot none' ran
1.44 ± 0.03 times faster than './y_before.bin build --sysroot none'
Cranelift makes api breaking changes often enough that this workflow
fails half of the time. As such in practice I completely ignore it's
result and push an update to a branch after Cranelift branches to test
everything on CI. In this update I immediately fix the fallout of api
breaking changes.
A new command ./y.rs bench is introduced for benchmarking. This change
allows skipping hyperfine installation in ./y.rs prepare and thus avoids
writing to ~/.cargo/bin.
Rename `assert_uninit_valid` intrinsic
It's not about "uninit" anymore but about "filling with 0x01 bytes" so the name should at least try to reflect that.
This is actually not fully correct though, as it does still panic for all uninit with `-Zstrict-init-checks`. I'm not sure what the best way is to deal with that not causing confusion. I guess we could just remove the flag? I don't think having it makes a lot of sense anymore with the direction that we have chose to go. It could be relevant again if #100423 lands so removing it may be a bit over eager.
r? `@RalfJung`
