Meta LLVM codegen regression tracking issue

[nikomatsakis]

What is this bug?

From time to time, we encounter regressions that seem to be due to an LLVM misoptimization or other bug (though sometimes it's a case of invalid unsafe code, or rustc generating bad IR). In such cases, we try to narrow the problem down to some LLVM IR that shows the bug independent of Rust; this can then be filed with LLVM and tracked separately. This metabug serves to track those sorts of bugs, and specifically cases where we have not yet managed to create a reproducible test case.

Indications that a bug may fit this category

• A common symptom is that enabling or disabling LTO causes the bug to appear or disappear.
• Similarly, bugs that appear shortly after LLVM upgades are common candidates.

Guide to diagnosing

If you'd like to help out, @pnkfelix and @nagisa plan to write a guide for how to extract LLVM IR from rustc. It has sadly not yet been written.

Tracked issues

• Segmentation fault on nightly and beta when running with --release Segmentation fault on nightly and beta when running with --release #49010
• aarch64 musl binaries panic since 2018-02-05 nightly aarch64 musl binaries panic since 2018-02-05 nightly #48967
• heisenbug: debug builds Integer::repr_discr has transient ICE on compile-fail/enum-discrim-too-small2.rs heisenbug: debug builds Integer::repr_discr has transient ICE on compile-fail/enum-discrim-too-small2.rs #47381

Priority

This bug is sometimes marked P-high when we find that there are a lot of such problems not yet diagnosed.

[gnzlbg]

If you'd like to help out, @pnkfelix and @nagisa plan to write a guide for how to extract LLVM IR from rustc. It has sadly not yet been written.

I end up doing this quite often, and what I do is the following:

• create a new crate that reproduces the issue, e.g., by adding whatever crate is at fault as a dependency, and using it from there

• minimize the crate by removing external dependencies (that is, moving everything relevant to the new crate)

• further minimize the issue by making the code shorter (there are tools that help with this like creduce)

• emit the LLVM-IR for all code involved (see below) and create a MWE in gcc.godbolt.org:

  • in godbolt choose LLVM-IR as programming language

  • use llc to compile the IR to a particular target as is:

    • -mattr enable target features, -march= selects target, -mcpu= the CPU, etc. You can go to your
    • if you have compiled rustc yourself somewhere, in the target directory you have binaries for llc, opt, etc. Commands like llc -march=help output all architectures available, which is useful because sometimes the Rust arch names and the LLVM names do not match

  • if you want to optimize the LLVM-IR, you can use opt to see how the LLVM optimizations transform it. I haven't used this much, so maybe others can give some tips here.

• once you have a godbolt link demonstrating the issue, it is pretty easy to fill in an LLVM bug.

To generate LLVM-IR. There are a couple of things to keep in mind, and one typically needs to use them together:

• RUSTFLAGS="--emit=llvm-ir" makes rustc spit llvm ir in the target directory
  • cargo llvm-ir [options] path spits the llvm-ir for a particular function at a path
    • cargo install cargo-asm installs cargo asm and cargo llvm-ir.
    • --build-type=debug emits code for debug builds, see other options there
  • debug info in LLVM IR can clutter the output a lot: RUSTFLAGS="-C debuginfo=0" is really useful
  • @eddyb mentioned a trick on IRC to prune a lot of LLVM-IR away by using unreachable_unchecked but I can't find the link to it anymore and I forgot to put it in my notes
• RUSTFLAGS="-C save-temps" outputs llvm bitcode at different stages during compilation, which is sometimes useful. One just needs to convert the bitcode files to .ll files using llvm-dis which should be in the target local compilation of rustc.

Also, I recall reading somewhere that we are now shipping some of the llvm utilities, so one probably does not need to have a rustc compiled from source to use the appropriate versions of llc,opt, llvm-dis, etc. locally, but I haven't had a change to test that yet.

[nikomatsakis]

@gnzlbg awesome, thanks! Maybe we can move these notes to the rustc-guide or forge or something, so that we can point at them.

[nagisa]

mentioned a trick on IRC to prune a lot of LLVM-IR away by using unreachable_unchecked but I can't find the link to it anymore and I forgot to put it in my notes

unreachable_unchecked is a dangerous tool as while yes, using it will remove all the unreachable code coming after it, LLVM proving it to be reachable will also remove code coming before it. It may also invoke other UB, and I’ve been burnt by it enough times that I simply opt to just delete the code and fix it up to compile again when minimising.

[gnzlbg]

@eddyb do you recall what it was?

[pnkfelix]

visiting for triage.

These are some awesome notes from @gnzlbg . In order to get this bug out of my own issue queue, I'll try to recreate the steps listed and simultaneously port them into docs that we can put on the rustc-guide (or forge or something, as @nikomatsakis said...)

[eddyb]

@gnzlbg Sorry, no. Do you mean something like this?

fn foo(x: Option<String>) -> String {
    match x {
        Some(s) => s,
        None => unsafe { unreachable_unchecked() }
    }
}

This should generate code that's effectively an unchecked variant field access, (x as Some).0, bypassing all the noise from unwrap or anything else that panics.
But it might be safer to use the abort intrinsic instead (which generates a trap).

[gnzlbg]

Maybe, I can't recall any more :/ In any case when there is an issue in the rust book repo where people can submit their own tips and tricks for this: rust-lang/rustc-dev-guide#162

[pnkfelix]

Visiting for triage: Given rust-lang/rustc-dev-guide#171, I am tempted to downgrade this to P-medium...

[pnkfelix]

visiting for triage and downgrading to P-medium, as I threatened last week.

[Centril]

Removing I-unsound as this issue doesn't track a specific known soundness hole.

[jyn514]

This meta-issue hasn't had subissues in a long time, even though we've found LLVM regressions since 2020. I'm going to close this for now and we can continue using individual issues to track miscompilations and regressions. Happy to be convinced otherwise if anyone feels strongly.