-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Add assume into NonZeroIntX::get
#119452
Add assume into NonZeroIntX::get
#119452
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
I would also like to check if we can just add valid range attribute to the function call. It seems to work. There is also a problem that |
5acf68b
to
b895a3e
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
…get_assume_nonzero, r=<try> Add assume into `NonZeroIntX::get` LLVM currently don't support range metadata for function arguments so it fails to optimize non zero integers using their invariant if they are provided using by-value function arguments. Related to rust-lang#119422 Related to llvm/llvm-project#76628 Related to rust-lang#49572
library/core/src/num/nonzero.rs
Outdated
if self.0 == 0 { | ||
// SAFETY: It is an invariant of this type. | ||
unsafe { | ||
crate::hint::unreachable_unchecked() | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if self.0 == 0 { | |
// SAFETY: It is an invariant of this type. | |
unsafe { | |
crate::hint::unreachable_unchecked() | |
} | |
} | |
unsafe { std::intrinsics::assume(self.0 != 0) }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Nilstrieb assume
is not const-stable, so it can’t be called here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably should be const stable then, I don't see any problems with that (cc @rust-lang/wg-const-eval)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah seems fine to mark that intrinsic as callable from stable const fn
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (5a3a8b4): comparison URL. Overall result: no relevant changes - 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 benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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 sizeResultsThis 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: 669.431s -> 669.699s (0.04%) |
Doesn't make compilation or the compiler faster, but that of course doesn't mean it's not worth it. Seems reasonable to add this (with an assume) but looks like @scottmcm wants to do the final decision on that :) |
@AngelicosPhosphoros: Could you also update the |
b895a3e
to
97f74e7
Compare
@EFanZh Done. |
I agree that this should be using And feel free to review if you notice it first, @Nilstrieb -- I just wanted to make sure it didn't end up waiting on a libs-api person who could be doing ACP reviews instead :) |
@Nilstrieb @RalfJung Do I need to run through whole stabilization process? |
It's an intrinsic, just mark it as stable, that's it. |
Yeah, the intrinsic is still unstable, just const-stable. So it cannot be called directly, just internally in stable const fn inside core/std. You can just add the attribute with wg-const-eval approval. |
@AngelicosPhosphoros For context, the reason for this gating is to be careful that we don't accidentally expose something that couldn't be done in (The conversation would be more complicated if it was an intrinsic for getting a random number or reading a file or something.) |
Closes rust-lang#76972 Blocks rust-lang#119452 Approved in rust-lang#119452 (comment)
The last perf run here looks good, but since the biggest reason this wasn't done before was perf concerns, I want to do another one as the code has changed, just from an abundance of caution. @bors try @rust-timer queue But r=me assuming the perf results are still good! 🤞 |
This comment has been minimized.
This comment has been minimized.
…get_assume_nonzero, r=<try> Add assume into `NonZeroIntX::get` LLVM currently don't support range metadata for function arguments so it fails to optimize non zero integers using their invariant if they are provided using by-value function arguments. Related to rust-lang#119422 Related to llvm/llvm-project#76628 Related to rust-lang#49572
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (8a63333): comparison URL. Overall result: ❌✅ regressions and improvements - 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. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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 sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 666.39s -> 663.51s (-0.43%) |
Does that mean that using assume is different compared to unreachable_unchecked? |
It's certainly different -- it changes the MIR, after all, such as fewer BBs by not having an With more stuff in the methods, having the cycles being maybe slightly higher is, I think, ok. Looking at the overall wall time, including the non-significant ones, I think it's fair to call this roughly neutral. And 3 seconds saved on bootstrap is nothing to sneeze at! @bors r+ rollup=never |
☀️ Test successful - checks-actions |
Finished benchmarking commit (2319be8): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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 sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 666.309s -> 665.459s (-0.13%) |
Instructions have a couple red in instruction counts for |
@rustbot label: +perf-regression-triaged |
LLVM currently don't support range metadata for function arguments so it fails to optimize non zero integers using their invariant if they are provided using by-value function arguments.
Related to #119422
Related to llvm/llvm-project#76628
Related to #49572