Stream: git-wasmtime

Topic: wasmtime / PR #10012 winch: Simplify the handling of `was...


view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 20:45):

saulecabrera opened PR #10012 from saulecabrera:winch-standardize-loads to bytecodealliance:main:

This commit aims to simplify how wasm_loads are currently handled in the compiler by reducing the number of invariants that need to be encoded at callsites which make their emission error prone.

Concretely this change:

<!--
Please make sure you include the following information:

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 20:45):

saulecabrera requested wasmtime-compiler-reviewers for a review on PR #10012.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 20:45):

saulecabrera requested fitzgen for a review on PR #10012.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 23:45):

github-actions[bot] commented on PR #10012:

Subscribe to Label Action

cc @saulecabrera

<details>
This issue or pull request has been labeled: "winch"

Thus the following users have been cc'd because of the following labels:

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2025 at 00:01):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2025 at 00:21):

alexcrichton merged PR #10012.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2025 at 15:14):

MarinPostma commented on PR #10012:

In the context of atomic operations, which only accept zero-extends, it seems to me that encoding signed and zero extends in a single enum is maybe a bit too loose. Maybe we could split it in two enums instead:

enum ExtendKind {
    Signed(ExtendSize),
    Zero(ExtendSize),
}

enum ExtendSize {
   I32extends8,
   //...
}

WIth that, we could avoid this check, for example: https://github.com/bytecodealliance/wasmtime/pull/9990/commits/53d2d25a91926751d650467700a3b536d296c26e#diff-a9f4061f11240b9ea041bd84fbaf01290ff679313f87e5085eeebdecf300f5bdR1374-R1377

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2025 at 15:15):

MarinPostma edited a comment on PR #10012:

In the context of atomic operations, which only accept zero-extends, it seems to me that encoding signed and zero extends in a single enum is maybe a bit too loose. Maybe we could split it in two enums instead:

enum ExtendKind {
    Signed(SignedExtendSize),
    Zero(ZeroExtendSize),
}

enum SignedExtendSize {
   I32extends8,
   //...
}

WIth that, we could avoid this check, for example: https://github.com/bytecodealliance/wasmtime/pull/9990/commits/53d2d25a91926751d650467700a3b536d296c26e#diff-a9f4061f11240b9ea041bd84fbaf01290ff679313f87e5085eeebdecf300f5bdR1374-R1377


Last updated: Jan 24 2025 at 00:11 UTC