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. #525

References:
https://github.com/WebAssembly/tool-conventions/blob/main/Lime.md
bytecodealliance/wasm-micro-runtime#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. bytecodealliance/wasm-micro-runtime#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 bytecodealliance/wasm-micro-runtime#4272

[yamt]

i filed llvm/llvm-project#140010 while testing this