[llvm] [MachineVerifier] Fix LiveInterval verification of unwinding instructions (PR #131565)

[Heejin Ahn via llvm-commits]

aheejin wrote:

> Well, this verifier check _should_ fire on an analogous, non-wasm test case, where a virtual register is defined after a potentially throwing call in an Itanium landingpad predecessor. In such a case, the value will be computed and the register value defined after the call, but if the call throws and we try to read the value from a landingpad, bad things will happen.
> 
> Our MIR representation is somewhat deficient because we don't have an equivalent of the LLVM IR `invoke` instruction, and this verifier check is making sure that CodeGen passes don't try to insert PHI-elimination code (and eventually possibly register fills) between the call, the terminating jump, and the landingpad.

In theory this can happen in Wasm too. It would be nice if we can query something like `MI.canThrow()` can replace `MI.isCall()` with that. Do you know why there is no `Throws` or something in this list of `MachineInstr` properties? https://github.com/llvm/llvm-project/blob/be6ccc98f38227db02164f17bfaf0ac86d800e4a/llvm/include/llvm/MC/MCInstrDesc.h#L148-L190
It would be nice if we can add one, but this probably is more work than it's worth, given that I don't have info on the complete set of all target instruction that can throw.

> I agree we need to relax the check for wasm and Windows asynch EH, because, as your test case points out, we no longer have the invariant that all landingpad predecessor blocks end in a potentially throwing call. They may end in seh.try.end (non-call label) or CLEANUPRET or some other runtime-mediated control transfer instruction.

If we can't do `MI.canThrow()` or something, we can probably not run the check here in case of Wasm/WinEH, even though this feels like a hacky solution, because we can have assignments (which may have been generated by PHIs, as you suggested) after a call.

https://github.com/llvm/llvm-project/pull/131565