`RangeToInclusive` code-generation much worse than equivilent `RangeTo`

[gamozolabs]

I have two copies of the exact same code, one using for _ in 0..65 and the other using for _ in 0..=64. The 0..65 one optimizes down to very simple code, however the 0..=64 version ends up emitting a large amount of unnecessary code.

---

RangeTo example

pub fn and_stuff(a: i32, mut b: i32) -> i32 {
    for _ in 0..65 {
        b &= a;
    }

    b
}

Emits (https://rust.godbolt.org/z/pcscMB):

example::and_stuff:
        mov     eax, edi
        and     eax, esi
        ret

---

RangeToInclusive example

pub fn and_stuff(a: i32, mut b: i32) -> i32 {
    for _ in 0..=64 {
        b &= a;
    }

    b
}

Emits (https://rust.godbolt.org/z/22JaO2):

.LCPI0_0:
        .zero   4
        .long   4294967295
        .long   4294967295
        .long   4294967295
example::and_stuff:
        movd    xmm0, esi
        movaps  xmm1, xmmword ptr [rip + .LCPI0_0]
        movss   xmm1, xmm0
        movd    xmm0, edi
        pshufd  xmm0, xmm0, 0
        pand    xmm0, xmm1
        pshufd  xmm1, xmm0, 78
        pand    xmm1, xmm0
        pshufd  xmm0, xmm1, 229
        pand    xmm0, xmm1
        movd    eax, xmm0
        and     eax, edi
        ret

[tesuji]

If you use -C opt-level=3, two snippets will output the same assembly: https://rust.godbolt.org/z/tfvYvi

[falk-hueffner]

I'm having the same issue, my code takes about twice as long with "..=", even with -C opt-level=3: https://rust.godbolt.org/z/yrPRd3
Here's a complete benchmark program: https://rust.godbolt.org/z/6hjAAZ

[miggazElquez]

The problem is fixed on 1.42, but is back on the beta 1.43 and on nightly :
https://rust.godbolt.org/z/vJHfta

[alex]

This no longer reproduces on a recent rustc. Should this be closed, or is it preferable to add a codegen test?

[clubby789]

Should have a test
@rustbot label +E-needs-test