Add an option to specify CFLAGS for wasm features and make lime1 the default

[yamt]

Add a cmake option WASI_SDK_CPU_CFLAGS to specify CFLAGS to control wasm features to enable/disable. Make the default -mcpu=lime1.

Comparing to the default "generic" target of the recent llvm, this effectively

• disables reference-types and bulk-memory (enable their partial counterparts instead)
• enables extended-const

Note: as of writing this, a few popular runtimes, including wasm3 and wasm-micro-runtime, don't support extented-const yet.

Note: regardless of this, wasi-libc enables necessary features for certain files. (bulk-memory and exception-handling)

cf. https://github.com/WebAssembly/wasi-sdk/issues/525

References: https://github.com/WebAssembly/tool-conventions/blob/main/Lime.md https://github.com/bytecodealliance/wasm-micro-runtime/issues/4272

[sbc100]

Should we have the wasi target default to lime1 instead?

[yamt]

Should we have the wasi target default to lime1 instead?

it's a valid solution. my feeling is it's app developers' choice which set of features it targets to though.

the intention of this PR is "do not enable extra features we ourselves (eg. libc) doesn't benefit from".

[sbc100]

Should we have the wasi target default to lime1 instead?

it's a valid solution. my feeling is it's app developers' choice which set of features it targets to though.

Up to a point this is true, but we also what sensible defaults. Developers who want to target specs older than out defaults can/should be asked to rebuild libc themselves, right?

My understanding was the lime1 was specifically designed as a sensible subset of generic that project like wasi-libc could use.

the intention of this PR is "do not enable extra features we ourselves (eg. libc) doesn't benefit from".

extended-const does benefit shared library builds (it allows data segments to express their offset without extra startup code).

[yamt]

Should we have the wasi target default to lime1 instead?

it's a valid solution. my feeling is it's app developers' choice which set of features it targets to though.

Up to a point this is true, but we also what sensible defaults. Developers who want to target specs older than out defaults can/should be asked to rebuild libc themselves, right?

My understanding was the lime1 was specifically designed as a sensible subset of generic that project like wasi-libc could use.

honestly speaking, i don't understand why "generic" and wasi should have different defaults. is "generic" meant for web?

the intention of this PR is "do not enable extra features we ourselves (eg. libc) doesn't benefit from".

extended-const does benefit shared library builds (it allows data segments to express their offset without extra startup code).

it's true. i'm not sure if extended-const is ubiquitous among non-web runtimes though.

[sunfishcode]

Could you comment on the practical impact of this change? Which features in the wasi-libc build are you looking to disable? Or is there some other purpose here?

[yamt]

Could you comment on the practical impact of this change? Which features in the wasi-libc build are you looking to disable? Or is there some other purpose here?

reference-types makes some environment unhappy. eg. https://github.com/bytecodealliance/wasm-micro-runtime/issues/3977

[sunfishcode]

i'm not sure if extended-const is ubiquitous among non-web runtimes though.

It is in some, it's behind a flag in others, and it's expected to be easy to implement for the rest. And it also happens to be shipping in all the web runtimes already. And, it enables significantly better dynamic libraries.

There's a tradeoff here, but unless we know of some significant burden this creates, I think it makes sense to keep the ecosystem moving forward, and leave extended-const enabled here.

[yamt]

i'm not sure if extended-const is ubiquitous among non-web runtimes though.

It is in some, it's behind a flag in others, and it's expected to be easy to implement for the rest. And it also happens to be shipping in all the web runtimes already. And, it enables significantly better dynamic libraries.

There's a tradeoff here, but unless we know of some significant burden this creates, I think it makes sense to keep the ecosystem moving forward, and leave extended-const enabled here.

ok. i filed an issue for wamr https://github.com/bytecodealliance/wasm-micro-runtime/issues/4272

[yamt]

i filed https://github.com/llvm/llvm-project/pull/140010 while testing this

[yamt]

Should we have the wasi target default to lime1 instead?

i gave a thought about this a bit.

coding-wise, it's trivial to patch llvm to make it a default for wasi. it's probably less confusing for users, especially when it's a bit difficult to specify -mcpu and friends for lto. (i feel a fundamental problem here is in llvm lto, not wasm though.)

otoh, i'm not sure if it's appropriate for wasip2 and later, where, iiuc, the linear memory assumption is planned to be lifted. having different defaults for wasip1 and wasip2 can be another source of confusion.

[yamt]

the ci error looks unrelated to this PR

 Submodule 'src/config' (https://git.savannah.gnu.org/git/config.git) registered for path 'src/config'
Submodule 'src/llvm-project' (https://github.com/llvm/llvm-project) registered for path 'src/llvm-project'
Submodule 'src/wasi-libc' (https://github.com/WebAssembly/wasi-libc) registered for path 'src/wasi-libc'
Cloning into '/home/runner/work/wasi-sdk/wasi-sdk/src/config'...
fatal: unable to access 'https://git.savannah.gnu.org/git/config.git/': The requested URL returned error: 502
fatal: clone of 'https://git.savannah.gnu.org/git/config.git' into submodule path '/home/runner/work/wasi-sdk/wasi-sdk/src/config' failed
Failed to clone 'src/config'. Retry scheduled
Cloning into '/home/runner/work/wasi-sdk/wasi-sdk/src/llvm-project'...
Cloning into '/home/runner/work/wasi-sdk/wasi-sdk/src/wasi-libc'...
Cloning into '/home/runner/work/wasi-sdk/wasi-sdk/src/config'...
fatal: unable to access 'https://git.savannah.gnu.org/git/config.git/': The requested URL returned error: 502
fatal: clone of 'https://git.savannah.gnu.org/git/config.git' into submodule path '/home/runner/work/wasi-sdk/wasi-sdk/src/config' failed
Failed to clone 'src/config' a second time, aborting
Error: Process completed with exit code 1.

can anyone with permission hit "rerun failed jobs"?

[yamt]

the last push was a conflict resolution

[kylo5aby]

@yamt Hello, how can I check whether a runtime supports lime1? Are there any test cases that can be compiled to WASM using wasi-sdk to verify this?

[sunfishcode]

@kylo5aby I've now opened https://github.com/WebAssembly/tool-conventions/pull/254 which contains a wast test file exercising all of the Lime1 features.