[clang] [WebAssembly] Enable multivalue and reference-types in generic CPU config (PR #80923)

[Derek Schuff via cfe-commits]

================
@@ -147,19 +147,25 @@ void WebAssemblyTargetInfo::setFeatureEnabled(llvm::StringMap<bool> &Features,
 bool WebAssemblyTargetInfo::initFeatureMap(
     llvm::StringMap<bool> &Features, DiagnosticsEngine &Diags, StringRef CPU,
     const std::vector<std::string> &FeaturesVec) const {
-  if (CPU == "bleeding-edge") {
-    Features["nontrapping-fptoint"] = true;
+  auto addGenericFeatures = [&]() {
     Features["sign-ext"] = true;
+    Features["mutable-globals"] = true;
+    Features["reference-types"] = true;
+    Features["multivalue"] = true;
+  };
+  auto addBleedingEdgeFeatures = [&]() {
+    addGenericFeatures();
+    Features["nontrapping-fptoint"] = true;
----------------
dschuff wrote:

MV and reftypes are required to use exnref, that's the thing that's on the critical path here. So yes, we definitely want to land these two without blocking on nontrapping-fptoint.

Relatedly (to nontrapping-fptoint, but unrelatedly to this PR), I prototyped a Binaryen pass to lower away LLVM's use of nontrapping-fptoint* which is what would allow us to improve codegen. I think it works, but I discovered that some of emscripten's tests fail when we enable nontrapping fptoint, and I haven't yet looked at why that's the case (either a bug in emscripten's tests, or a bug in V8's implementation of nontrapping fptoint). We'd need to also fix that to unblock enabling this. 

* (This isn't exactly the same as a full lowering of nontrapping-fptoint as spec'ed, because it takes advantage of knowledge of the semantics of LLVM's fptosi intrinsics)

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