Open alion02 opened 1 week ago
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Nilstrieb (or someone else) some time within the next two weeks.
Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review
and S-waiting-on-author
) stays updated, invoking these commands when appropriate:
@rustbot author
: the review is finished, PR author should check the comments and take action accordingly@rustbot review
: the author is ready for a review, this PR will be queued again in the reviewer's queue@bors try @rust-timer queue
Insufficient permissions to issue commands to rust-timer.
@alion02: :key: Insufficient privileges: not in try users
The job x86_64-gnu-tools
failed! Check out the build log: (web) (plain)
Might as well try both suggested new impls of unwrap_unchecked
.
@bors try @rust-timer queue
Awaiting bors try build completion.
@rustbot label: +S-waiting-on-perf
:hourglass: Trying commit 3d67c904ddf9d60a64926ea22dde26f026b37444 with merge b25d7106c60170d8c49899e6980085f954e38542...
The job dist-x86_64-linux
failed! Check out the build log: (web) (plain)
:broken_heart: Test failed - checks-actions
@bors r-
The job x86_64-gnu-tools
failed! Check out the build log: (web) (plain)
The job x86_64-gnu-llvm-17
failed! Check out the build log: (web) (plain)
@bors try
:hourglass: Trying commit fd9898875659a115ff8ea3618e5994e91706ff72 with merge f471a93d679c528e1a81f68cfad53044030a8d6a...
The job x86_64-gnu-tools
failed! Check out the build log: (web) (plain)
:sunny: Try build successful - checks-actions
Build commit: f471a93d679c528e1a81f68cfad53044030a8d6a (f471a93d679c528e1a81f68cfad53044030a8d6a
)
Queued f471a93d679c528e1a81f68cfad53044030a8d6a with parent 69ffc0d3a3c619009bcb27b8f61d810e27b12612, future comparison URL. There are currently 10 preceding artifacts in the queue. It will probably take at least ~13.2 hours until the benchmark run finishes.
When I tried #102151 it only lead to regressions. But a lot has changed since then and this isn't the same approach so maybe the results will be different this time.
@bors try
Generate a new try build, the old one is based on a broken master commit AFAICT.
:hourglass: Trying commit fd9898875659a115ff8ea3618e5994e91706ff72 with merge 4a9bbb36013e82d74e72489eb03bf87c7730e48c...
@rust-timer queue
Awaiting bors try build completion.
@rustbot label: +S-waiting-on-perf
:sunny: Try build successful - checks-actions
Build commit: 4a9bbb36013e82d74e72489eb03bf87c7730e48c (4a9bbb36013e82d74e72489eb03bf87c7730e48c
)
Queued 4a9bbb36013e82d74e72489eb03bf87c7730e48c with parent 3170bd9d1bab03eeb15552686f2de84e75360e56, future comparison URL. There are currently 6 preceding artifacts in the queue. It will probably take at least ~8.1 hours until the benchmark run finishes.
Finished benchmarking commit (4a9bbb36013e82d74e72489eb03bf87c7730e48c): comparison URL.
Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.
@bors rollup=never @rustbot label: -S-waiting-on-perf -perf-regression
This benchmark run did not return any relevant results for this metric.
This benchmark run did not return any relevant results for this metric.
Bootstrap: 675.885s -> 674.118s (-0.26%) Artifact size: 315.88 MiB -> 315.83 MiB (-0.02%)
nom-json
got a lot faster (unless it's spurious...?)Much smaller impact overall than I expected, but still vaguely interesting.
By the way, I noticed that the x86 backend (which is presumably what these benchmarks are running on) is more resilient to assume
spam than ARM. Probably something that can/should be fixed on the LLVM side, but for now — are we able to run a benchmark on ARM?
We don't have the tools/facilities set up for benchmarking Arm, no.
I assume running rustc-perf locally should work on an arm linux box.
any improvements from this PR are LLVM bugs, but evidently the LLVM bugs exist. you should report them upstream, but I'd be ok with a bit of papering over them in the meantime. i would prefer the offset_of based approach over this.
Relevant ACP. Relevant godbolt.
Attempt to clean up the LLVM IR we generate based on the assumption that we usually don't want to
assume
the value of the discriminant (because it sticks around in the IR and randomly inhibits optimizations).