Run initial SIMD spec tests #330
Conversation
|
@yurydelendik noted that wasmtime-debug might also need support for v128: e.g., https://github.com/yurydelendik/wasmtime/blob/853238529e4df416e36a364c7df99019c3cabdd1/wasmtime-debug/src/transform/simulate.rs#L162 |
sunfishcode
left a comment
There was a problem hiding this comment.
I forget where you asked me this, but to your question about exposing Uimm128:
Stepping back and looking at it, Uimm128 is actually misnamed, because it's not a scalar integer immediate, like the other Uimm* types are. (We should perhaps rename them too, as Uimm* isn't super clear, but that's a separate issue). If we renamed Uimm128 to something like V128Imm, I think it'd be fine to expose that in APIs. And it could have a Display implementation so that you don't have to use {:?} as the PR currently does.
07402f6 to
60d1c88
Compare
60d1c88 to
cf228ba
Compare
cf228ba to
4e995ad
Compare
4e995ad to
77b12cc
Compare
|
I guess global get/set is still not working... |
77b12cc to
4609291
Compare
|
This is almost there; only bytecodealliance/cranelift#993 needed to address the failing |
5928a59 to
8209a60
Compare
8209a60 to
44c6479
Compare
Update wabt (see issue in pepyakin/wabt-rs#56). Due to changes in wabt, the spec tests are updated as well.
For this to work the wasm-c-api must add support for the V128 type (e.g. through __uint128_t)
5cf5fff to
ff7f800
Compare
|
@sunfishcode thanks for all the debugging help! |
This change will allow us to verify that the SIMD implementation matches what is expected in the spec tests published to https://github.com/WebAssembly/simd/tree/master/test/core/simd. Some notes:
build.rsand enables SIMD for spec testsThis is a work in progress.