Fails to fully optimize logically equivalent match patterns with nested

[ZhonghaoPan-nju]

I tried these codes: (opt-level=3)
https://godbolt.org/z/b3je31qea

pub fn main() {
    let x = 1;
    let y = 2;

    assert_eq!(
        3,
        match (x, y) {
            (1, 1) => 1,
            (2, 2) => 2,
            (1..=2, 2) => 3,
            _ => 4,
        }
    );

    assert_eq!(
        3,
        match ((x, y),) {
            ((1, 1),) => 1,
            ((2, 2),) => 2,
            ((1..=2, 2),) => 3,
            _ => 4,
        }
    );
}

and:

pub fn main() {
    let mut x = (2 - 1);
    x += 1727276569 - 101200722;	
    x -= 1626075847;
    {
        let mut y = 3;
        y *= 2057990635 / 1;
        y /= 2057990635;
        assert_eq!(3, match (x, y) {
            (1, 1) => 1,
            (2, 2) => 2,
            (1..=2, 2) => 3,
            _ => 4,
        });
        assert_eq!(3, match ((x, y),) {
            ((1, 1),) => 1,
            ((2, 2),) => 2,
            ((1..=2, 2),) => 3,
            _ => 4,
        });
    }
}

I expected to see this happen:

example::main::h0b7eacf4acc29bea:
        ret

Instead, this happened:

example::main::h0b7eacf4acc29bea:
        sub     rsp, 56
        mov     dword ptr [rsp + 4], 4
        mov     qword ptr [rsp + 8], 0
        lea     rsi, [rip + .Lanon.a978cc5b56b2e232a190db3ec3b8f702.0]
        lea     r8, [rip + .Lanon.a978cc5b56b2e232a190db3ec3b8f702.2]
        lea     rdx, [rsp + 4]
        lea     rcx, [rsp + 8]
        xor     edi, edi
        call    qword ptr [rip + core::panicking::assert_failed::haa00447c26f4b1ca@GOTPCREL]

The compiler fails to recognize that let mut x and let mut y ultimately resolve to constant values 1 and 2 respectively in the second code example. While rustc's constant propagation typically handles such cases effectively, this particular pattern involving mutable variables with arithmetic operations appears to prevent the optimization.
I'd appreciate any insights into why the compiler can't deduce the final constant values in this scenario.

Meta

rustc 1.85.0-nightly (d117b7f21 2024-12-31)
binary: rustc
commit-hash: d117b7f211835282b3b177dc64245fff0327c04c
commit-date: 2024-12-31
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.6

[theemathas]

Not a bug. Rust integers default to being i32 unless some type information forces it to be some other type.

In your second code, when you do y *= 2057990635 / 1;. You are computing 3 * 2057990635. The result of this operation is 6173971905, which doesn't fit in an i32, which can hold values at most 2147483647. Therefore, your code has an integer overflow.

In debug mode, rust will panic as soon as you do this multiplication. In release mode, which is what your godbolt link uses, the result "wraps around". Therefore, after the multiplication, y is not equal to 6173971905, but is instead equal to 1879004609. Then, after y /= 2057990635;, y is set to 0. As a result, the assertion fails, so the assembly reflects this behavior.

You can check this by actually running the code, as opposed to inspecting the assembly. You will see that it does, in fact, panic from overflow in debug mode, and panic from failing the assertion in release mode.

[ZhonghaoPan-nju]

@theemathas Thank you for your patient explanations - they've helped me better understand Rust's behavior! I'll go ahead and close this issue now.