RangeInclusive and Range bits are not optimizes a way but also not used in a function

[vDorst]

I tried this code: Also godbolt link https://rust.godbolt.org/z/9qs4cTP4v

pub struct MB {
    addr: u8,
}

pub fn new(addr: u8) -> Option<MB> {
    if !(1..=247).contains(&addr) {
        return None;
    }
    Some(MB { addr })
}

I expected to see this happen:

I was trying this code to see what kind of assemble the compilers makes.
I tried different optimize levels.
I see with optimize levels s and 1, that the RangeInclusive bits are still there but not used in the function.
function is self takes about 5 instructions and the RangeInclusive code about 40 instruction, which is dead code.

Instead, this happened:
RangeInclusive bits removed in all the optimize levels.
I was using a similar code on a embedded device.

FYI: It also happens with Range . Remove the = before 247.

Meta

I see this happen on stable and nightly both for x86_64 and thumbv6/v7.

[scottmcm]

This is, unfortunately, well known. s and z aren't necessarily smaller https://internals.rust-lang.org/t/should-default-recommended-opt-level-for-minimizing-binary-size-be-s-or-z/19685/4?u=scottmcm

It'll be optimized out in -O (which is opt-level=2).

[saethlin]

Please open issues if you see any more problems like this. I think this general situation is more of a problem than our issue tracker suggests. If you report them we'll be more aware of the trend, and we can paper over individual situations like this one. I think that's what my linked PR does.

[vDorst]

@scottmcm @saethlin maybe to clarify.
With opt_level s the assembly of the generated function is fine and optimized.

example::new:
        lea     eax, [rdi - 1]
        cmp     al, -9
        setb    al
        mov     edx, edi
        ret

But the RangeInclusive bits are not removed and not used.
@saethlin so I am not sure if inline will help in this case.

[saethlin]

#[inline] does more than just apply an optimization hint. I disassembled the rlib files that come out of compiling that example code and confirmed that my PR does reduce the objdump output to just one function.