Update our baseline and generic CPU models for WebAssembly

[alexrp]

Currently, we use LLVM's generic model for both the generic and baseline models. LLVM's generic model for WebAssembly somewhat annoyingly represents a moving target that can change with any given LLVM version; it's basically just "what the major implementations support at this point in time". This makes it outright wrong as a generic model by our definition, but also a bad choice for a baseline model since our notion of "baseline" means wide compatibility, and that should clearly include more than just the major WebAssembly implementations. (An example of a problematic feature currently included in generic would be reference_types.)

So, the first order of business here should be to switch our generic model to LLVM's mvp model, which, as the name implies, targets a minimum viable WebAssembly implementation with no post-1.0 features. That can be done today while still mapping baseline to LLVM's generic.

Secondly, there is a WATC proposal to add a lime1 model to LLVM to address the problem of there not being a good baseline model:

• Propose a new LLVM CPU configuration: Lime1 WebAssembly/tool-conventions#235
• [WebAssembly] Support the new "Lime1" CPU llvm/llvm-project#112035

The feature set proposed there seems to me to be a very reasonable one for a baseline model. So, if that proposal is accepted, I think we should switch our baseline for WebAssembly to lime1 after we update to LLVM 20.

This may involve a bit of work in wasm2c to add support for a couple of features. Note that neither LLVM nor our self-hosted backend make use of multivalue in the mvp ABI, so we don't actually need to support that in wasm2c. That only leaves relatively simple features like nontrapping_fptoint and extended_const.

[alexrp]

cc @Luukdegram

[alexrp]

FYI, the WATC proposal for lime1 has been merged.

[andrewrk]

Everything you said made sense to me except for this bit:

This may involve a bit of work in wasm2c to add support for a couple of features.

While I wouldn't necessarily be against adding those features to wasm2c, I think the null hypothesis would be to disable those features when generating zig1.wasm.

[alexrp]

While I wouldn't necessarily be against adding those features to wasm2c, I think the null hypothesis would be to disable those features when generating zig1.wasm.

Right, I should have clarified that we only need to implement those minor features if we actually want to be able to build zig1.wasm against lime1 as spec'd. I personally think that's a nice thing to do just because the purpose of lime1 is specifically to be a solid baseline model for WebAssembly that most engines agree on.

Whatever we decide to do in that regard, though, I agree that the first step would be to disable any lime1 features that we don't yet support in wasm2c.

[Luukdegram]

cc @Luukdegram

For whatever it's worth, I agree with the changes outlined in the OP. Not only does it halter LLVM upgrades, it's not always clear for users of the Zig toolchain that upgrading their compiler can potentially involve enabling cpu features when targeting WebAssembly. So overall this is a good improvement to status quo, in my opinion.