wasm features enabled by default with wasi-sdk clang

[sbc100]

I'm currently looking at adding a few features to the default CPU in llvm: https://reviews.llvm.org/D77908

I'm guessing that wasi-sdk users are mostly targeting wasmtime and wasmer which should not have a problem with any stage 5 features I guess? So its probably fine, but wanted to raise this issue in case anyone has any concerns.

If we want to be conservative we could have wasi-sdk clang default to the mvp CPU maybe?

[sunfishcode]

I expect nontrapping-float-to-int and sign-extension-ops are fine to just enable.

For multi-value, let's talk through how we want to manage the transition first. The new C struct return ABI is behind a separate flag, though the LLVM struct return ABI does change with -mmulti-value. We'll want to transition to the new C struct return ABI by default, and we'll want to transition witx and WASI to using multi-value returns. There are enough moving pieces here that I'd prefer to have a plan before we make changes.

[kripken]

I expect nontrapping-float-to-int and sign-extension-ops are fine to just enable.

I hear about people running wasi-sdk code in wasm3, v8, WAMR, etc. v8 and wasm3 at least support those two, but I'm not sure about the others (and if they've enabled them by default).

(I guess in the worst case bugs will be filed...)

[vshymanskyy]

I think it should be safe to enable finished proposals by default: https://github.com/WebAssembly/proposals/blob/master/finished-proposals.md
With additional flags to disable them.

[sunfishcode]

Let's continue the conversation in WebAssembly/tool-conventions#158.

wasi-sdk doesn't have any patches against upstream, so wasi-sdk will do whatever LLVM does, and that's now being discussed in WebAssembly/tool-conventions#158.