-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Emit fewer assume
s now that we have range
metadata on parameters
#135610
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
r? @fee1-dead rustbot has assigned @fee1-dead. Use |
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Emit fewer `assume`s now that we have `range` metadata on parameters We still need the `assume` for the *target* type's range, but we no longer need it for the *source* type's range. Admittedly there's one test not properly handled by LLVM today, but it's synthetic, so I'd still be fine doing this and just updating the test once LLVM fixes the bug (llvm/llvm-project#123278). All the other optimization tests still pass. Hopefully this means less crud for LLVM to churn through in `opt` builds...
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
This comment was marked as outdated.
This comment was marked as outdated.
This comment has been minimized.
This comment has been minimized.
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Emit fewer `assume`s now that we have `range` metadata on parameters We still need the `assume` for the *target* type's range, but we no longer need it for the *source* type's range. The first stab at this regressed a test, but thanks to good advice in llvm/llvm-project#123278 (comment) the second commit here changes how we emit these range assertions to the form that LLVM apparently likes better (and, conveniently, is easier to emit too) which got that test passing again 🎉 Hopefully this means less crud for LLVM to churn through in `opt` builds...
We still need the `assume` for the *target* type's range, but we no longer need it for the *source* type's range. Admittedly there's one test not properly handled by LLVM today, but it's synthetic, so I'd still be fine doing this and just updating the test once LLVM fixes the bug. All the other optimization tests still pass. Hopefully this means less crud for LLVM to churn through in `opt` builds...
Thank you dtcxzyw in LLVM 123278 for pointing out that we were doing this in a suboptimal way.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (28bc505): comparison URL. Overall result: ❌ regressions - no action neededBenchmarking 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 Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -4.5%, secondary -1.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary -2.3%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResults (primary -0.0%, secondary 0.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 763.784s -> 764.347s (0.07%) |
Well, ok, then, I guess I'm leaving in the assumes :/ |
@rustbot author |
We still need the
assume
for the target type's range, but we no longer need it for the source type's range.The first stab at this regressed a test, but thanks to good advice in llvm/llvm-project#123278 (comment) the second commit here changes how we emit these range assertions to the form that LLVM apparently likes better (and, conveniently, is easier to emit too) which got that test passing again 🎉
Hopefully this means less crud for LLVM to churn through in
opt
builds...