Suboptimal code generated for alignment checks and similar via number.trailing_zeros() >= bit_count

[schreter]

Typically, one would write val & 7 == 0 to check whether val is aligned to 8B. However, Clippy complains and says it would be nicer to write it as val.trailing_zeros() >= 3. Although it is disputable whether this is really more readable, the problem is that the code generated is significantly worse.

For example, let's take this code:

pub fn check_align_trailing_zeros(val: usize) -> bool {
    val.trailing_zeros() >= 3
}

pub fn check_align_mask(val: usize) -> bool {
    val & 7 == 0
}

I expected to see the same optimal code generated. However, the compiler indeed generates separate instruction for trailing_zeros() instruction and additional compare, instead of a single instruction.

Code generated on x64:

example::check_align_trailing_zeros:
        test    rdi, rdi
        je      .LBB0_1
        bsf     rax, rdi
        cmp     eax, 3
        setae   al
        ret
.LBB0_1:
        mov     eax, 64
        cmp     eax, 3
        setae   al
        ret

example::check_align_mask:
        test    dil, 7
        sete    al
        ret

Code generated on ARM:

example::check_align_trailing_zeros:
        rbit    x8, x0
        clz     x8, x8
        cmp     w8, #2
        cset    w0, hi
        ret

example::check_align_mask:
        tst     x0, #0x7
        cset    w0, eq
        ret

This happens with the newest Rust 1.67 as well as with older versions and in nightly.

Checking of trailing_zeros/trailing_ones and leading_zeros/leading_ones with >/>= operators against n can be mapped to checking via a mask of n+1/n ones at the tail (for trailing_*) or head (for leading_*) of the mask word and comparing against 0 for *_zeroes (which is implicitly done and set as ZERO/EQ flag in CPU flags after the TEST operation, i.e., it boils down to a single instruction) or the mask word for *_ones (which boils down to two instructions).

[Noratrieb]

https://rust-lang.github.io/rust-clippy/master/#verbose_bit_mask

Clippy does at least list it as a possible downside of the lint.

[khei4]

This was fixed by https://reviews.llvm.org/D143368.

[schreter]

@khei4

This was fixed by https://reviews.llvm.org/D143368.

Thanks. Any ETA estimate when it will land in Rust compiler (TBH I have no idea how and how often llvm is pulled)? I just tested with nightly and the code generated is still suboptimal.

[khei4]

@schreter

Any ETA estimate when it will land in Rust compiler (TBH I have no idea how and how often llvm is pulled)?

Sorry, I also don't know when on Rust side. (I guess hopefully LLVM release would be in few weeks, as you may know https://github.com/llvm/llvm-project/milestone/20.)

[nikic]

Thanks. Any ETA estimate when it will land in Rust compiler (TBH I have no idea how and how often llvm is pulled)? I just tested with nightly and the code generated is still suboptimal.

This will land in Rust nightly around August with the LLVM 17 upgrade.

Assigning to myself to check back when it's time.

[nikic]

Godbolt: https://godbolt.org/z/KP7s3vjTn

Fixed by #114048, needs codegen test.