Function calls in logic expressions sometimes cause optimization misses

[BlaCoiso]

Calling functions, including const ones, on a logic expression (eg a || b) sometimes cause certain optimizations to be missed

I tried this code:

#[inline]
pub const fn a1(b: u8) -> bool {
    !b.is_ascii()
}

#[inline]
pub const fn a2(b: u8) -> bool {
    b.is_ascii_control()
}

pub const fn check1(b: u8) -> bool {
    let a1 = a1(b);
    let a2 = a2(b);
    a1 || a2
}

// this should generate the exact same code as check1 but it doesn't
pub const fn check2(b: u8) -> bool {
    a1(b) || a2(b)
}

Expected result: both functions (check1 and check2) generate the same assembly code

Actual result:

example::check1:
        add     dil, -32
        cmp     dil, 95
        setae   al
        ret

example::check2:
        test    dil, dil
        js      .LBB1_1
        cmp     dil, 32
        setb    cl
        cmp     dil, 127
        sete    al
        or      al, cl
        ret
.LBB1_1:
        mov     al, 1
        ret

Godbolt link: https://godbolt.org/z/vfPe13G8P

Additionally, changing the comparison order affects optimization:

// this optimizes correctly and generates same code as check1 despite being equivalent
// const fns have no side effects and logical or is commutative
pub const fn check3(b: u8) -> bool {
    a2(b) || a1(b)
}

Meta

rustc --version --verbose:

rustc 1.60.0-nightly (84322efad 2022-01-23)
binary: rustc
commit-hash: 84322efad553c7a79c80189f2d1b9197c1aa005f
commit-date: 2022-01-23
host: x86_64-pc-windows-msvc
release: 1.60.0-nightly
LLVM version: 13.0.0

[the8472]

Replacing || with | seems to solve this. It looks similar to #88204

[BlaCoiso]

This could be related to short circuiting, where the compiler is trying to only evaluate the second expression when the first one is false, even when the second expression has no side effects and evaluating both expressions at the same time would generate more optimized code. That would explain why | solves this, as | doesn't do short circuiting and always evaluates both sides of the expression, making these optimizations possible.

Edit: Could be related to #83623

This code is generating the same assembly as check2:

pub const fn check3(b: u8) -> bool {
    if a1(b) { true } else { a2(b) }
}

[workingjubilee]

Correct.

It's actually somewhat well-known, unfortunately, that the optimization you want is often made invalid by the language semantics, including here:

• "Short-circuit evaluation", Wikipedia
• "The Select Story", Juneyoung Lee

I do not see an obvious way to resolve this in the general case, as the optimizer is not allowed to simply resolve the second function always. I assume we could try to use our knowledge of the by-value, side-effect-free nature of the operations in this case.