Tracking Issue for feature(nonzero_leading_trailing_zeros)

[andjo403]

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.

[leonardo-m]

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.

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()
}

-O:

foo1:
    test    edi, edi
    je      .LBB0_2
    bsf     eax, edi
    ret
.LBB0_2:
    mov     eax, 32
    ret

foo2:
    bsf     eax, edi
    ret

-O -C target-cpu=native:

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?

[andjo403]

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

[leonardo-m]

The architecture I'm using is quite standard. A distributable binary could probably use it as "universal target".
I don't know much common is going to be an instruction like tzcnt in the future. If you think a similar instruction will be sufficiently uncommon then please ignore my comments here :-)

[m-ou-se]

@rfcbot merge

cc @rust-lang/wg-const-eval

[rfcbot]

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @sfackler

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.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

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.

[andjo403]

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
//! If an intrinsic is supposed to be used from a const fn with a rustc_const_stable attribute,
//! the intrinsic's attribute must be rustc_const_stable, too. Such a change should not be done
//! without T-lang consulation, because it bakes a feature into the language that cannot be
//! replicated in user code without compiler support.