wasmtime / Issue #1650 Use `[u8; 16]` instead of `u128` f... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / Issue #1650 Use `[u8; 16]` instead of `u128` f...

Wasmtime GitHub notifications bot (May 04 2020 at 18:06):

I am not married to this proposal: we could instead add a pretty-printer to wrap Vals and print the Val::V128 variants as either hex or converted by to_le_bytes(). Even better would be to figure out what the lane types of the V128 are supposed to be and print as that. I'll close this and try one of those approaches if someone has a strong opinion (or really any opinion :big_smile:) but this at least makes it easier to troubleshoot why tests are failing.

Wasmtime GitHub notifications bot (May 04 2020 at 18:18):

github-actions[bot] commented on Issue #1650:

Subscribe to Label Action

cc @peterhuene

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

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

peterhuene: wasmtime:api

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

Learn more.
</details>

Wasmtime GitHub notifications bot (May 04 2020 at 18:52):

alexcrichton commented on Issue #1650:

Oh seeing this I remember now that https://github.com/bytecodealliance/wasmtime/pull/689 shows that we're wavering back and forth on this. That was motivated by https://github.com/bytecodealliance/wasmtime/commit/3d69e04659a9dade78fa80a76e69e3f1b9d1af07#r36326017, so @joshtriplett would you mind helping to weigh in here?

Wasmtime GitHub notifications bot (May 05 2020 at 17:24):

joshtriplett commented on Issue #1650:

A few different considerations:

Does the change here impact code generation? Do we get better assembly code by shifting values out of a u128 than we get by offsetting into a slice and extracting bytes?

For debugging, can we improve the debugging prints of the V128 to make it easier to see the individual components? (For instance, showing it in hex, providing _ between each 32-bit value, etc?)

How would this interact with the actual use of full u128 values in Rust and WebAssembly?

Wasmtime GitHub notifications bot (May 05 2020 at 17:25):

joshtriplett edited a comment on Issue #1650:

A few different considerations:

Does the change here impact code generation? Do we get better assembly code by shifting values out of a u128 than we get by offsetting into a slice and extracting bytes?

For debugging, can we improve the debugging prints of the V128 to make it easier to see the individual components? (For instance, showing it in hex, providing _ between each 32-bit value, etc?) Because looking at a [u8; 16] doesn't necessarily make it easy to "see" a u32 or u64 either.

How would this interact with the actual use of full u128 values in Rust and WebAssembly?

Wasmtime GitHub notifications bot (May 05 2020 at 17:25):

joshtriplett edited a comment on Issue #1650:

A few different considerations:

Does the change here impact code generation? Do we get better assembly code by shifting values out of a u128 than we get by offsetting into a slice and extracting bytes?

For debugging, can we improve the debugging prints of the V128 to make it easier to see the individual components? (For instance, showing it in hex, providing _ between each 32-bit value, etc?) Looking at a [u8; 16] doesn't necessarily make it easy to "see" a u32 or u64 either.

How would this interact with the actual use of full u128 values in Rust and WebAssembly?

Wasmtime GitHub notifications bot (May 05 2020 at 18:09):

abrown commented on Issue #1650:

* Does the change here impact code generation? Do we get better assembly code by shifting values out of a u128 than we get by offsetting into a slice and extracting bytes?
This should not impact Cranelift codegen; this is an internal detail for the boxing of values used in Wasmtime (e.g. if a user passes in a V128 from the CLI somehow it would be stored internally as either [u8; 16] or u128 (depending on what we decide) for the brief time before it is passed in to the compiled code.
* For debugging, can we improve the debugging prints of the V128 to make it easier to see the individual components? (For instance, showing it in hex, providing _ between each 32-bit value, etc?) Looking at a [u8; 16] doesn't necessarily make it easy to "see" a u32 or u64 either.
I think this is actually the better long-term solution. Lazily, I didn't really want to implement this but looking into it a bit it seems like we could coerce the V128 to look like whatever the V128Pattern from wast looks like. Let me try that instead of this approach.

* How would this interact with the actual use of full u128 values in Rust and WebAssembly?

I don't really see how it does. It seemed to me like a very internal detail to boxed values but I could be missing something.

Wasmtime GitHub notifications bot (May 05 2020 at 18:09):

abrown edited a comment on Issue #1650:

Does the change here impact code generation? Do we get better assembly code by shifting values out of a u128 than we get by offsetting into a slice and extracting bytes?

This should not impact Cranelift codegen; this is an internal detail for the boxing of values used in Wasmtime (e.g. if a user passes in a V128 from the CLI somehow it would be stored internally as either [u8; 16] or u128 (depending on what we decide) for the brief time before it is passed in to the compiled code.

For debugging, can we improve the debugging prints of the V128 to make it easier to see the individual components? (For instance, showing it in hex, providing _ between each 32-bit value, etc?) Looking at a [u8; 16] doesn't necessarily make it easy to "see" a u32 or u64 either.

I think this is actually the better long-term solution. Lazily, I didn't really want to implement this but looking into it a bit it seems like we could coerce the V128 to look like whatever the V128Pattern from wast looks like. Let me try that instead of this approach.

How would this interact with the actual use of full u128 values in Rust and WebAssembly?

I don't really see how it does. It seemed to me like a very internal detail to boxed values but I could be missing something.

Wasmtime GitHub notifications bot (May 06 2020 at 20:31):

joshtriplett commented on Issue #1650:

If this doesn't have any performance impact, I have no objection. But if the primary concern is debugging, I think it's worth trying a simple change to our debugging prints first.

Wasmtime GitHub notifications bot (May 11 2020 at 20:45):

abrown commented on Issue #1650:

Closing, see https://github.com/bytecodealliance/wasmtime/issues/1681.

Last updated: Nov 22 2024 at 16:03 UTC