================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
