-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Tracking Issue for feature(nonzero_leading_trailing_zeros) #79143
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
It seems on my (common) architecture it doesn't give an advantage: #![feature(nonzero_leading_trailing_zeros)]
use std::num::NonZeroU32;
pub fn foo1(x: u32) -> u32 {
x.trailing_zeros()
}
pub fn foo2(x: NonZeroU32) -> u32 {
x.trailing_zeros()
}
foo1:
test edi, edi
je .LBB0_2
bsf eax, edi
ret
.LBB0_2:
mov eax, 32
ret
foo2:
bsf eax, edi
ret
foo1:
tzcnt eax, edi
ret
foo2:
tzcnt eax, edi
ret So the question is: is this NonZero method worth keeping? Are the architectures where it gives a performance advantage common enough? |
but as you show in your example if you want to make a distributable binary and due to this not set the target-cpu there is a big difference |
The architecture I'm using is quite standard. A distributable binary could probably use it as "universal target". |
@rfcbot merge cc @rust-lang/wg-const-eval |
Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
started to make the stabilization PR but hit a problem I think that const_cttz needs to be stabilized for this to be stabilized from https://github.com/rust-lang/rust/blob/master/library/core/src/intrinsics.rs#L16 |
…trailing_zeros, r=m-ou-se Stabilize nonzero_leading_trailing_zeros Stabilizing nonzero_leading_trailing_zeros and due to this also stabilizing the intrinsic cttz_nonzero FCP finished here: rust-lang#79143 (comment) `@rustbot` modify labels: +T-libs Closes rust-lang#79143
Tracking issue for trailing_zeros and leading_zeros for non zero types as introduced by #79114.
The feature gate for the issue is
#![feature(nonzero_leading_trailing_zeros)]
.On many architectures, this functions can perform better than trailing_zeros/leading_zeros on the underlying integer type, as special handling of zero can be avoided.
The text was updated successfully, but these errors were encountered: