[llvm] Ensure NoTrapAfterNoreturn is false for the wasm backend (PR #65876)

[Matt Harding via llvm-commits]

================
@@ -37,6 +37,11 @@ static cl::opt<bool>
     EnableTrapUnreachable("trap-unreachable", cl::Hidden,
                           cl::desc("Enable generating trap for unreachable"));
 
+static cl::opt<bool> EnableNoTrapAfterNoreturn(
+    "no-trap-after-noreturn", cl::Hidden,
+    cl::desc("Do not emit a trap instruction for 'unreachable' IR instructions "
+             "after noreturn calls, even if --trap-unreachable is set."));
----------------
majaha wrote:

I added the flag because I couldn't test how the feature effects wasm output without the ability to enable it from the command line.

Being able to test NoTrapAfterNoreturn's behaviour prevents this bug from regressing. In the future, people may want to stop forcing TrapUnreachable to true and NoTrapAfterNoreturn to false, if the wasm backend improves and it stops being necessary for correctness. It seems to me that if a feature exists in llvm and is able to cause bugs, we should be able to test it.

While the NoTrapAfterNoreturn option is false by default, this can be overridden by frontends like clang or the Rust compiler. [Like this change to the Rust compiler](https://github.com/rust-lang/rust/pull/110494/files#diff-eac3d5ef63f39b7914ae9015f31b8d87353ea8fbcd5b02a7335dd86c557e7625), which is the original motivation behind this pull request (expand the code down and look for the line with `createTargetMachine()` for an idea of how it works). This is actually the purpose of the TargetOptions class, to pass (command line) options from the frontend to llvm.

The wasm backend should still produce valid code even if it receives the NoTrapAfterNoreturn option, is my feeling.

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