Update our baseline and generic CPU models for WebAssembly #21818
Comments
alexrp
added
enhancement
|
cc @Luukdegram |
|
FYI, the WATC proposal for |
|
Everything you said made sense to me except for this bit:
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 Whatever we decide to do in that regard, though, I agree that the first step would be to disable any |
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. |
As discussed in ziglang#21818, generic is a poor baseline model because that model is a moving target in LLVM. Instead, use mvp, which has no features enabled.
…embly. See: WebAssembly/tool-conventions#235 This is not *quite* using the same features as the spec'd lime1 model because LLVM 19 doesn't have the level of feature granularity that we need for that. This will be fixed once we upgrade to LLVM 20. Part of ziglang#21818.
As discussed in ziglang#21818, generic is a poor baseline model because that model is a moving target in LLVM. Instead, use mvp, which has no features enabled.
…embly. See: WebAssembly/tool-conventions#235 This is not *quite* using the same features as the spec'd lime1 model because LLVM 19 doesn't have the level of feature granularity that we need for that. This will be fixed once we upgrade to LLVM 20. Part of ziglang#21818.
…embly. See: WebAssembly/tool-conventions#235 This is not *quite* using the same features as the spec'd lime1 model because LLVM 19 doesn't have the level of feature granularity that we need for that. This will be fixed once we upgrade to LLVM 20. Part of ziglang#21818.
…embly. See: WebAssembly/tool-conventions#235 This is not *quite* using the same features as the spec'd lime1 model because LLVM 19 doesn't have the level of feature granularity that we need for that. This will be fixed once we upgrade to LLVM 20. Part of ziglang#21818.
As discussed in ziglang#21818, generic is a poor baseline model because that model is a moving target in LLVM. Instead, use mvp, which has no features enabled.
…embly. See: WebAssembly/tool-conventions#235 This is not *quite* using the same features as the spec'd lime1 model because LLVM 19 doesn't have the level of feature granularity that we need for that. This will be fixed once we upgrade to LLVM 20. Part of ziglang#21818.
…embly. See: WebAssembly/tool-conventions#235 This is not *quite* using the same features as the spec'd lime1 model because LLVM 19 doesn't have the level of feature granularity that we need for that. This will be fixed once we upgrade to LLVM 20. Part of ziglang#21818.
As discussed in ziglang#21818, generic is a poor baseline model because that model is a moving target in LLVM. Instead, use mvp, which has no features enabled.
…embly. See: WebAssembly/tool-conventions#235 This is not *quite* using the same features as the spec'd lime1 model because LLVM 19 doesn't have the level of feature granularity that we need for that. This will be fixed once we upgrade to LLVM 20. Part of ziglang#21818.
As discussed in ziglang#21818, generic is a poor baseline model because that model is a moving target in LLVM. Instead, use mvp, which has no features enabled.
…embly. See: WebAssembly/tool-conventions#235 This is not *quite* using the same features as the spec'd lime1 model because LLVM 19 doesn't have the level of feature granularity that we need for that. This will be fixed once we upgrade to LLVM 20. Part of ziglang#21818.
As discussed in ziglang#21818, generic is a poor baseline model because that model is a moving target in LLVM. Instead, use mvp, which has no features enabled.
…embly. See: WebAssembly/tool-conventions#235 This is not *quite* using the same features as the spec'd lime1 model because LLVM 19 doesn't have the level of feature granularity that we need for that. This will be fixed once we upgrade to LLVM 20. Part of ziglang#21818.
Currently, we use LLVM's
genericmodel for both the generic and baseline models. LLVM'sgenericmodel 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 ingenericwould bereference_types.)So, the first order of business here should be to switch our generic model to LLVM's
mvpmodel, 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'sgeneric.Secondly, there is a WATC proposal to add a
lime1model to LLVM to address the problem of there not being a good baseline model: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
lime1after we update to LLVM 20.This may involve a bit of work in
wasm2cto add support for a couple of features. Note that neither LLVM nor our self-hosted backend make use ofmultivaluein themvpABI, so we don't actually need to support that inwasm2c. That only leaves relatively simple features likenontrapping_fptointandextended_const.The text was updated successfully, but these errors were encountered: