UI test issue-64655-extern-rust-must-allow-unwind.rs#fat0 triggers LLVM assert when compiled for i686 target

[voidc]

This was discovered in #81825 (comment), which adds support for Linux pidfds to standard library. With the changes in the PR, the issue-64655-extern-rust-must-allow-unwind test triggers an LLVM assertion during compilation. This is similar to the issue described in #83854.
As a workaround, the failing test revision was disabled provisionally.

Minimal reproduction:

1. Checkout 2208705
2. Run src/ci/docker/run.sh --dev i686-gnu and build stage1 compiler
3. Run echo "fn main() {}" | build/i686-unknown-linux-gnu/stage1/bin/rustc - "--target=i686-unknown-linux-gnu" -Clto=fat

Output:

/checkout/src/llvm-project/llvm/lib/CodeGen/RegAllocFast.cpp:883: void {anonymous}::RegAllocFast::defineVirtReg(llvm::MachineInstr&, unsigned int, llvm::Register, bool): Assertion `PhysReg != 0 && "Register not assigned"' failed.

[Aaron1011]

Normally, we would get the LLVM error message "ran out of registers during register allocation" here. However, Rust's LLVM diagnostic handler does not emit diagnostics immediately - it queues them up for the main thread to handle. As a result, we hit the assertion before the main thread has a change to print the diagnostic.

Bug https://bugs.llvm.org/show_bug.cgi?id=42569 looks potentially related

[Aaron1011]

I've reduced this to a 5 megabyte LLVM IR file. Unfortunatey, bugpoint is not really set up to handle such a large file (the 'Checking instruction' phase used up 9GB of ram before I killed it):

ir_crash.zip

The crash can be reproduced by unzipping ir_crash.zip, and running llc -O0 -relocation-model=pic simpler_ir.ll

[Aaron1011]

Using llvm-reduce, I was able to reduce it down to this IR:

target triple = "i686-unknown-linux-gnu"

define void @my_fn() personality i32 undef {
  invoke void undef()
          to label %6 unwind label %3

1:
  %2 = icmp eq i8 %4, 0
  ret void

3:
  %4 = phi i8 [ 0, %0 ], [ 1, %6 ]
  %5 = landingpad { i8*, i32 }
          cleanup
  br label %1

6:
  invoke fastcc void undef(i32 undef)
          to label %7 unwind label %3

7:
  ret void
}

[Aaron1011]

This appears to be fixed in the latest LLVM trunk: https://godbolt.org/z/h96n5WqeG

[bjorn3]

I don't see a declaration of undef there. And there are two calling conventions used to call it. The default and fastcc.

[Aaron1011]

I bisected the LLVM fix to llvm/llvm-project@c1dc2672

[Aaron1011]

It might end up being easier to just wait for the LLVM 13 bump in #87570

[Aaron1011]

@bjorn3 - undefis LLVM's undef value - apparently, it can be used in a function call. The calling convention doesn't matter for the first (default cc) function call - we get the same assertion failure either way.

[nikic]

The LLVM fix was backported in #87610, so this issue should be fixed.