Skip to content
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

Variables with rustc_layout_scalar_valid_range are not assumed to be in their range #82224

Closed
Soveu opened this issue Feb 17, 2021 · 2 comments
Closed
Labels
A-layout Area: Memory layout of types A-mir-opt Area: MIR optimizations C-enhancement Category: An issue proposing an enhancement or a PR with one. I-slow Issue: Problems and improvements with respect to performance of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Soveu
Copy link
Contributor

Soveu commented Feb 17, 2021

I have noticed that for example NonZero integers are not assumed to be non-zero.

pub fn leading_zeros(x: NonZeroU32) -> u32 {
    //unsafe { std::intrinsics::assume(x.get() != 0) };
    x.get().leading_zeros()
}

pub fn is_zero(x: NonZeroU32) -> bool {
    //unsafe { std::intrinsics::assume(x.get() != 0) };
    x.get() == 0
}

example::leading_zeros:
        test    edi, edi     ; check if it is zero
        je      .LBB1_2
        bsr     eax, edi
        xor     eax, 31
        ret
.LBB1_2:
        mov     eax, 32
        ret

example::is_zero:
        test    edi, edi     ; check if it is zero
        sete    al
        ret

(it also affects division)

Manually adding intrinsics::assume fixes that issue, but this cannot be used in const functions.
Related to #79114 and #79134

@camelid camelid added A-layout Area: Memory layout of types C-enhancement Category: An issue proposing an enhancement or a PR with one. I-slow Issue: Problems and improvements with respect to performance of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-mir-opt Area: MIR optimizations labels Feb 26, 2021
@syvb
Copy link
Contributor

syvb commented Feb 28, 2021

Duplicate of #49572?

@nagisa
Copy link
Member

nagisa commented Mar 9, 2021

Closing as duplicate.

@nagisa nagisa closed this as completed Mar 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-layout Area: Memory layout of types A-mir-opt Area: MIR optimizations C-enhancement Category: An issue proposing an enhancement or a PR with one. I-slow Issue: Problems and improvements with respect to performance of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants