Merge multi-value proposal into spec by binji · Pull Request #1145 · WebAssembly/spec

binji · 2020-03-19T20:57:46Z

See the multi-value proposal here:

https://github.com/WebAssembly/multi-value

This PR is built on top of the following PRs:

Merge nontrapping-float-to-int proposal into spec #1143 (merge nontrapping-float-to-int)
Merge sign-extension-ops proposal into spec #1144 (merge sign-extension-ops)

rossberg · 2020-03-20T08:24:00Z

Hm, GH isn't good at dealing with dependent PRs. Is there a reason that we cannot merge proposals one at a time?

binji · 2020-03-20T18:00:57Z

Is there a reason that we cannot merge proposals one at a time?

We can, but when we discussed this in the WG meeting, we decided it would be valuable to explicitly have them ordered with the actual PRs ready to go.

I just realized I can make this a little easier to read by having each PR against the branch of the previous PR, so it's easier to see the diffs. I'll try that instead.

binji · 2020-03-20T19:18:49Z

OK, updated. PTAL

rossberg

I found one (earlier) mistake that I fixed in the repo, see comment.

document/core/appendix/properties.rst

rossberg

Thanks!

See the multi-value proposal here: https://github.com/WebAssembly/multi-value This PR is built on top of the following PRs: * #1143 (merge nontrapping-float-to-int) * #1144 (merge sign-extension-ops)

Ms2ger · 2020-04-27T13:41:12Z

proposals/multi-value/Overview.md

@@ -0,0 +1,196 @@
+# Multi-value Extension


@binji I only realized now that you added the proposals/ dir too. Was that intentional?

It was; I thought we decided to do this so we could easily see that you could easily see which proposals had been merged into the spec. That said, it was a long time ago and I could be misremembering.

At least it matches my memory as well. :)

This enables three proposals by default since they've been merged into the upstream specification: * `saturating-float-to-int` - WebAssembly/spec#1143 * `sign-extension` - WebAssembly/spec#1144 * `multi-value` - WebAssembly/spec#1145 Most of the fallout from this is in the test suite with lots of `--enable` flags getting removed and some tests which now unconditionally pass also getting removed. Two spec tests explicitly pass `--disable` until the spec test submodule is updated.

This was merged into the wasm spec upstream in WebAssembly/spec#1145, so let's follow the spec and enable it by default here as well!

This enables three proposals by default since they've been merged into the upstream specification: * `saturating-float-to-int` - WebAssembly/spec#1143 * `sign-extension` - WebAssembly/spec#1144 * `multi-value` - WebAssembly/spec#1145 Most of the fallout from this is in the test suite with lots of `--enable` flags getting removed and some tests which now unconditionally pass also getting removed. Two spec tests explicitly pass `--disable` until the spec test submodule is updated.

chfast · 2020-07-07T11:09:43Z

As this extensions is merged, and it modifies existing test files, is there a way to send new tests for 1.0?

Ms2ger · 2020-07-07T11:30:17Z

Are you asking whether someone is maintaining a test suite specifically for Wasm 1.0, excluding tests / test changes for proposals that have been merged since? If so, I don't think so. You can always submit tests to the master branch here, of course.

chfast · 2020-07-07T11:34:33Z

Yes, I can submit tests to maser, but I will not be able to use them directly from master. Thanks for the answer anyway. I don't want to start longer discussion here.

* Upgrade to latest Sphinx release (2.4.4) (#1171) Fixes #1157 * Support 4GB of memory both in initial and max. * [interpreter] Strictify and specify .bin.wast format (#1173) * Merge nontrapping-float-to-int proposal into spec (#1143) See the non-trapping-float-to-int-conversions proposal here: https://github.com/WebAssembly/nontrapping-float-to-int-conversions * Merge sign-extension-ops proposal into spec (#1144) See the sign-extension-ops proposal here: https://github.com/WebAssembly/sign-extension-ops This PR is built on top of #1143 (merge nontrapping-float-to-int). * Merge multi-value proposal into spec (#1145) See the multi-value proposal here: https://github.com/WebAssembly/multi-value This PR is built on top of the following PRs: * #1143 (merge nontrapping-float-to-int) * #1144 (merge sign-extension-ops) * [interpreter] Remove junk in README * [interpreter] Remove junk in README * [spec] Fix grammar for fractions (#1178) * [spec] Add missing i64.extend32_s syntax (#1179) * [js-api][web-api] Fix some markup errors. * Add a README to the proposals directory. * Add more address overflow tests (#1188) There are already tests for effective address overflow, but those have a large value baked into the offset. These tests all use `1` as the immediate offset, and use `-1` for the address on the stack, which may be compiled differently. * Add a test for non-treelike behavior of stack (#961) We've recently found a bug in a WebAssembly library we've been working with where we're mapping WebAssembly to a tree-like IR internally. The way we parse into this representation, however, has a bug when the function isn't itself tree-like but rather exibits properties that exploit a stack machine. For example this isn't so straightforward to represent in a tree-like fashion: (import "" "a" (func $foo)) (import "" "b" (func $foo (result i32))) (func (result i32) call $b call $b call $a i32.xor) The extra `call $a` in the middle is valid `WebAssembly` but needs special treatment when converting to a more tree-like IR format. I figured it'd be good to ensure there's a spec test covering this case as we currently pass the suite of spec tests but still contain this bug! * [js-api] Various editorial improvements. * [js-api] Replace pseudo-ASCII characters by normal ones. This also required disambiguating the references to "module", as there are now two definitions by that name. * [js-api] Improve prose in 'run a host function'. * [js-api] Improve some of the multi-value prose. * Synchronize js-api tests. * Add script to synchronize js-api tests. Co-authored-by: Ng Zhi An <ngzhian@gmail.com> Co-authored-by: Alon Zakai <azakai@google.com> Co-authored-by: Ben Smith <binji@chromium.org> Co-authored-by: Ms2ger <Ms2ger@igalia.com> Co-authored-by: Alex Crichton <alex@alexcrichton.com>

This bumps the `haskell-wasm` submodule to include the changes from SPY/haskell-wasm@b1874df and SPY/haskell-wasm@b816e04, which change the `Block`, `Loop`, and `If` instructions to use a `BlockType` instead of a `ResultType`. This allows these instructions to have multiple result values, as described in this WebAssembly proposal: WebAssembly/spec#1145 To adapt the code on the `crucible-wasm` side, I have introduced a `getBlockResultType` function to convert from a `BlockType` to a `ResultType`, which is heavily inspired by a similar function in `haskell-wasm`. I have also factored out some code shared in common between `translateFunction` and `genInstruction`'s case for `Block` so that I do not have to conjure up a fresh `BlockType` in `translateFunction`. Part of #1069.

See the multi-value proposal here: https://github.com/WebAssembly/multi-value This PR is built on top of the following PRs: * WebAssembly#1143 (merge nontrapping-float-to-int) * WebAssembly#1144 (merge sign-extension-ops)

binji changed the base branch from master to merge-sign-extension-ops March 20, 2020 19:16

rossberg mentioned this pull request Mar 23, 2020

[spec] Fix two omissions WebAssembly/multi-value#43

Merged

rossberg reviewed Mar 23, 2020

View reviewed changes

document/core/appendix/properties.rst Show resolved Hide resolved

rossberg approved these changes Mar 23, 2020

View reviewed changes

binji mentioned this pull request Apr 8, 2020

Invalid JavaScript tests for multi-value functions WebAssembly/multi-value#44

Closed

binji force-pushed the merge-sign-extension-ops branch from 87f2a5a to 270c879 Compare April 9, 2020 18:04

Merge multi-value proposal into spec

d3a8b88

See the multi-value proposal here: https://github.com/WebAssembly/multi-value This PR is built on top of the following PRs: * #1143 (merge nontrapping-float-to-int) * #1144 (merge sign-extension-ops)

binji force-pushed the merge-multi-value branch from c59da7c to d3a8b88 Compare April 9, 2020 18:08

binji changed the base branch from merge-sign-extension-ops to master April 9, 2020 18:09

binji merged commit 484180b into master Apr 9, 2020

binji deleted the merge-multi-value branch April 9, 2020 18:09

Ms2ger reviewed Apr 27, 2020

View reviewed changes

Ms2ger mentioned this pull request Apr 28, 2020

Add a README to the proposals directory. #1186

Merged

This was referenced May 4, 2020

multi-value support dfinity-side-projects/winter#14

Closed

Multiple func results paritytech/parity-wasm#288

Merged

alexcrichton mentioned this pull request May 5, 2020

Enabled merged proposals by default WebAssembly/wabt#1405

Merged

alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request May 6, 2020

Enable the multi-value proposal by default

5e5b17d

This was merged into the wasm spec upstream in WebAssembly/spec#1145, so let's follow the spec and enable it by default here as well!

alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request May 6, 2020

Enable the multi-value proposal by default

4e4b597

This was merged into the wasm spec upstream in WebAssembly/spec#1145, so let's follow the spec and enable it by default here as well!

alexcrichton mentioned this pull request May 6, 2020

Enable the multi-value proposal by default bytecodealliance/wasmtime#1667

Merged

alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request May 6, 2020

Enable the multi-value proposal by default

1530ec6

This was merged into the wasm spec upstream in WebAssembly/spec#1145, so let's follow the spec and enable it by default here as well!

alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request May 6, 2020

Enable the multi-value proposal by default

8a1f94e

This was merged into the wasm spec upstream in WebAssembly/spec#1145, so let's follow the spec and enable it by default here as well!

alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request May 6, 2020

Enable the multi-value proposal by default

573f0e6

This was merged into the wasm spec upstream in WebAssembly/spec#1145, so let's follow the spec and enable it by default here as well!

RyanGlScott mentioned this pull request Mar 27, 2023

crucible-wasm: Support latest version of haskell-wasm GaloisInc/crucible#1072

Merged

deadblackclover mentioned this pull request Jul 18, 2023

Does wasmi support the Wasm multi-value proposal? wasmi-labs/wasmi#739

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Merge multi-value proposal into spec#1145

Merge multi-value proposal into spec#1145
binji merged 1 commit intomasterfrom
merge-multi-value

binji commented Mar 19, 2020

Uh oh!

rossberg commented Mar 20, 2020

Uh oh!

binji commented Mar 20, 2020

Uh oh!

binji commented Mar 20, 2020

Uh oh!

rossberg left a comment

Uh oh!

Uh oh!

rossberg left a comment

Uh oh!

Ms2ger Apr 27, 2020

Uh oh!

binji Apr 27, 2020

Uh oh!

rossberg Apr 27, 2020

Uh oh!

chfast commented Jul 7, 2020

Uh oh!

Ms2ger commented Jul 7, 2020

Uh oh!

chfast commented Jul 7, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

binji commented Mar 19, 2020

Uh oh!

rossberg commented Mar 20, 2020

Uh oh!

binji commented Mar 20, 2020

Uh oh!

binji commented Mar 20, 2020

Uh oh!

rossberg left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rossberg left a comment

Choose a reason for hiding this comment

Uh oh!

Ms2ger Apr 27, 2020

Choose a reason for hiding this comment

Uh oh!

binji Apr 27, 2020

Choose a reason for hiding this comment

Uh oh!

rossberg Apr 27, 2020

Choose a reason for hiding this comment

Uh oh!

chfast commented Jul 7, 2020

Uh oh!

Ms2ger commented Jul 7, 2020

Uh oh!

chfast commented Jul 7, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants