Incorrect code generated by MIR optimization on nightly

[Amanieu]

trafficstars

#[inline]
pub fn imm8(x: u32) -> u32 {
    let mut out = 0u32;
    out |= (x >> 0) & 0xff;
    out
}

#[inline(never)]
pub fn inner(fields: u32) -> i64 {
    imm8(fields).rotate_right(((fields >> 8) & 0xf) << 1) as i32 as i64
}

fn main() {
    let val = inner(0xe32cf20f);
    println!("{val:#x}");
}

This code normally prints 0xfffffffff0000000 but when compiled with O -C debug-assertions=on -Zmir-opt-level=2 it produces 0x0 instead. This was noticed because MIR optimization is enabled by default on the current nightly.

This is the LLVM IR for the inner function with -C no-prepopulate-passes. Notice how the inputs to llvm.fshr.i32 (used by rotate_right) are 0, which is incorrect.

define i64 @_ZN4test5inner17hd60ec7d5b1d44c39E(i32 %fields) unnamed_addr #0 {
start:
  %0 = alloca i32, align 4
  %_13.0 = lshr i32 %fields, 0
  br label %bb3

bb3:                                              ; preds = %start
  %_10.0 = lshr i32 %fields, 8
  br label %bb1

bb1:                                              ; preds = %bb3
  %_7 = and i32 %_10.0, 15
  %_11.0 = shl i32 %_7, 1
  br label %bb2

bb2:                                              ; preds = %bb1
  call void @llvm.lifetime.start.p0(i64 4, ptr %0)
  %1 = call i32 @llvm.fshr.i32(i32 0, i32 0, i32 %_11.0)
  store i32 %1, ptr %0, align 4
  %_3 = load i32, ptr %0, align 4
  call void @llvm.lifetime.end.p0(i64 4, ptr %0)
  br label %bb4

bb4:                                              ; preds = %bb2
  %2 = sext i32 %_3 to i64
  ret i64 %2
}

[matthiaskrgr]

@rustbot prioritize

[steffahn]

@rustbot label regression-from-stable-to-nightly, I-unsound, A-mir-opt, T-compiler

[JakobDegen]

Can someone execute the snippet with -Zdump-mir=all and upload the resulting mir-dump directory somewhere? That should allow me to debug from my phone 😆

[Amanieu]

https://gist.github.com/Amanieu/183f034864c71a580b2f3347abc5b83d

[steffahn]

I’ve made a gist originally, too, but it looks like you can’t see all the files there. (Afaict only 300 of the 401 files show up.) Here’s a repo https://github.com/steffahn/rust_issue_101973

Edit: One downside of a repo (compared to a gist) is that I might want to get rid of it eventually; AFAIK, this shouldn’t be needed for too long anyway though.

[tmiasko]

With an assertion instead of println:

$ cat a.sh
#!/bin/bash
rustc -O -C debug-assertions=on a.rs && ./a
$ cargo-bisect-rustc --preserve --without-cargo --script ./a.sh
...
********************************************************************************
Regression in bc4b39c271bbd36736cbf1c0a1ac23d5df38d365
********************************************************************************

Individual builds from https://github.com/rust-lang/rust/pull/101152#issuecomment-1230950321, point to #100239 cc @RalfJung

[RalfJung]

Ouch. That probably means the unsoundness was already possible before my PR (as explained there, the check it removes was ineffective), but is easier to trigger now.

Cc @oli-obk @rust-lang/wg-mir-opt something is wrong in ConstProp handling of shifts and/or casts and/or bit-ops.

Is there a reproducer that does not need shifts and casts and a bitop? That would make the issue easier to track down.

[RalfJung]

FWIW it prints 0xfffffffff0000000 in Miri so the interpreter is probably fine, and it's probably a problem with the ConstProp pass itself.

[Amanieu]

The original code was much more complex. I minimized it as much as I could, but at this point even removing a useless >> 0 will cause the bug to no longer trigger.

[RalfJung]

Yeah I quite appreciate that it does fit in a few lines now. :)

[RalfJung]

The -Zmir-opt-level=2 is not needed, but indeed the bug needs -O -C debug-assertions=on to trigger. And inlining. Very strange.

ConstProp code is super hard to read and full of subtle (usually barely documented) invariants, so... this could be an interesting one to track down.

[RalfJung]

The inlined code looks fine, but it has the basic blocks in a strange order, which might explain why the ConstProp bug only occurs if inlining happens first.

The code just before ConstProp has this

    bb0: {
        StorageLive(_2);                 // scope 0 at ../tmp/constprop.rs:10:5: 10:65
        StorageLive(_3);                 // scope 0 at ../tmp/constprop.rs:10:5: 10:58
        StorageLive(_4);                 // scope 0 at ../tmp/constprop.rs:10:5: 10:17
        StorageLive(_5);                 // scope 0 at ../tmp/constprop.rs:10:10: 10:16
        _5 = _1;                         // scope 0 at ../tmp/constprop.rs:10:10: 10:16
        _4 = const 0_u32;                // scope 1 at ../tmp/constprop.rs:3:19: 3:23
        StorageLive(_12);                // scope 2 at ../tmp/constprop.rs:4:12: 4:27
        StorageLive(_13);                // scope 2 at ../tmp/constprop.rs:4:12: 4:20
        StorageLive(_14);                // scope 2 at ../tmp/constprop.rs:4:13: 4:14
        _14 = _5;                        // scope 2 at ../tmp/constprop.rs:4:13: 4:14
        _15 = CheckedShr(_14, const 0_i32); // scope 2 at ../tmp/constprop.rs:4:12: 4:20
        assert(!move (_15.1: bool), "attempt to shift right by `{}`, which would overflow", const 0_i32) -> bb3; // scope 2 at ../tmp/constprop.rs:4:12: 4:20
    }

    bb1: {
        _8 = move (_10.0: u32);          // scope 0 at ../tmp/constprop.rs:10:32: 10:45
        StorageDead(_9);                 // scope 0 at ../tmp/constprop.rs:10:44: 10:45
        _7 = BitAnd(move _8, const 15_u32); // scope 0 at ../tmp/constprop.rs:10:31: 10:52
        StorageDead(_8);                 // scope 0 at ../tmp/constprop.rs:10:51: 10:52
        _11 = CheckedShl(_7, const 1_i32); // scope 0 at ../tmp/constprop.rs:10:31: 10:57
        assert(!move (_11.1: bool), "attempt to shift left by `{}`, which would overflow", const 1_i32) -> bb2; // scope 0 at ../tmp/constprop.rs:10:31: 10:57
    }

    bb2: {
        _6 = move (_11.0: u32);          // scope 0 at ../tmp/constprop.rs:10:31: 10:57
        StorageDead(_7);                 // scope 0 at ../tmp/constprop.rs:10:56: 10:57
        StorageLive(_16);                // scope 3 at /home/r/src/rust/rustc/library/core/src/num/uint_macros.rs:238:38: 238:42
        _16 = _4;                        // scope 3 at /home/r/src/rust/rustc/library/core/src/num/uint_macros.rs:238:38: 238:42
        StorageLive(_17);                // scope 3 at /home/r/src/rust/rustc/library/core/src/num/uint_macros.rs:238:44: 238:45
        _17 = _6;                        // scope 3 at /home/r/src/rust/rustc/library/core/src/num/uint_macros.rs:238:44: 238:45
        _3 = rotate_right::<u32>(move _16, move _17) -> bb4; // scope 3 at /home/r/src/rust/rustc/library/core/src/num/uint_macros.rs:238:13: 238:56
                                         // mir::Constant
                                         // + span: /home/r/src/rust/rustc/library/core/src/num/uint_macros.rs:238:13: 238:37
                                         // + literal: Const { ty: extern "rust-intrinsic" fn(u32, u32) -> u32 {rotate_right::<u32>}, val: Value(<ZST>) }
    }

One possible explanation would be if ConstProp iterated the basic blocks in order, then by the time it reaches rotate_right, the last assignment to _4 it saw is _4 = const 0_u32 in bb0. There is another assignment to _4 in bb3, which is executed before bb2, but maybe somehow my change made it so that this is not taken into account properly any more.

[RalfJung]

Turns out the actual problem was an early return that I added which skipped more code than it should have -- fixed by https://github.com/rust-lang/rust/pull/102045.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-critical