LLVM crash: Basic Block does not have terminator!

[dtolnay]

The following is minimized from https://crates.io/crates/lalrpop, which is regressed as of nightly-2021-08-15.

fn bump() -> Option<usize> {
    unreachable!()
}

fn take_until(terminate: impl Fn() -> bool) {
    loop {
        if terminate() {
            return;
        } else {
            bump();
        }
    }
}

fn main() {
    take_until(|| true);
}

$ rustc +nightly-2021-08-14 main.rs
$ ./main
$ # :)

$ rustc +nightly-2021-08-15 main.rs
Basic Block in function '_ZN4main10take_until17h0067b8a660429bc9E' does not have terminator!
label %3
in function _ZN4main10take_until17h0067b8a660429bc9E
LLVM ERROR: Broken function found, compilation aborted!

$ rustc +nightly-2021-08-15 --version --verbose
rustc 1.56.0-nightly (8007b506a 2021-08-14)
binary: rustc
commit-hash: 8007b506ac5da629f223b755f5a5391edd5f6d01
commit-date: 2021-08-14
host: x86_64-unknown-linux-gnu
release: 1.56.0-nightly
LLVM version: 12.0.1

[dtolnay]

Relevant commit range is 5a19ffe...8007b50. Of the 9 landed PRs, the ones that look potentially relevant to codegen are #85020 and #83417. @lrh2000 @tmandry @erikdesjardins @oli-obk

[dtolnay]

I tried all the merge commits in order of merge:

• d0a10b2: pass
• 32c3f2d: pass
• c6094fc: pass
• 99efc51: pass
• fa26929: pass
• 136eaa1: pass
• a59e885: pass
• e55c13e: pass
• 8007b50: regressed

so that narrows this down to #83417 (@erikdesjardins @oli-obk).

[Aaron1011]

This passes under Miri, so I suspect that we've exposed an LLVM bug.

[dtolnay]

Not sure it's an LLVM bug because it seems the IR is broken even before any LLVM passes. I tried:

$ rustc +nightly-2021-08-14 -Cno-prepopulate-passes --emit=llvm-ir src/main.rs -o before.ll
$ opt before.ll  # ok

$ rustc +nightly-2021-08-15 -Cno-prepopulate-passes --emit=llvm-ir src/main.rs -o after.ll
$ opt after.ll
opt: after.ll:287:1: error: expected instruction opcode
bb1:                                              ; preds = %bb0
^

Before: https://paste.rs/o7U
After: https://paste.rs/ftk
Diff: https://paste.rs/gWL.diff

The main::take_until looks like legitimately broken input IR. Notice the extractvalue insts relocated from the front of bb4 to the end of bb0 (invalidly after the terminator).

What in LLVM is actually running during a -Cno-prepopulate-passes build?

[oli-obk]

I think we should do a quick revert and then figure this out without any pressure

[oli-obk]

the mir changes are

    bb2: {
-        _0 = const ();                   // scope 0 at src/main.rs:8:13: 8:19
-        drop(_1) -> bb5;                 // scope 0 at src/main.rs:13:1: 13:2
+        drop(_1) -> bb4;                 // scope 0 at src/main.rs:13:1: 13:2
    }

    bb3: {
-        _5 = bump() -> [return: bb4, unwind: bb6]; // scope 0 at src/main.rs:10:13: 10:19
+        _5 = bump() -> [return: bb0, unwind: bb5]; // scope 0 at src/main.rs:10:13: 10:19
                                         // mir::Constant
                                         // + span: src/main.rs:10:13: 10:17
                                         // + literal: Const { ty: fn() -> std::option::Option<usize> {bump}, val: Value(Scalar(<ZST>)) }
-    }
-
-    bb4: {
-        goto -> bb0;                     // scope 0 at src/main.rs:6:5: 12:6
    }

that seems totally reasonable, so we need to check what codegen_llvm makes of it

[oli-obk]

I wonder why the goto collapse only happens if the zst assignment is eliminated. it seems like we need to preserve bb4 in mir or inject it in codegen_llvm, but first we should find out why the goto collapse is happening at all

[tmiasko]

There are no control-flow simplification passes after removal of dead local variables, which is why it didn't happen so far. Still, it seems a bit surprising it wasn't reported earlier:

pub fn f(_a: Option<String>) -> Option<u32> {
    loop {
        f(None);
        ()
    }
}

fn main() {
    f(None);
}

$ rustc +stable a.rs
Basic Block in function '_ZN1a1f17h9901a33e93da62b7E' does not have terminator!
label %4
in function _ZN1a1f17h9901a33e93da62b7E
LLVM ERROR: Broken function found, compilation aborted!

Adding a new cleanup pass before codegen would be one way to address this.

[erikdesjardins]

I swear half of my PRs break the compiler 😅

I'm excited for what bugs arise when we start using undef for uninitialized consts...

Revert PR: #88056

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-critical

[oli-obk]

The issue was not fixed, it is an LLVM crash on stable as #88043 (comment) shows

[dtolnay]

Relabeling regression because #88043 (comment) worked in 1.51.0. It bisects to nightly-2021-03-02 (e37a13c...4f20caa).

[dtolnay]

#78360 is the only codegen change in that nightly. @tmiasko @wesleywiser

[wesleywiser]

Reopening to track the stable-to-stable regression.

[wesleywiser]

Backport was merged.