abrown opened PR #2475 from fix-1681
to main
:
This should be helpful as we investigate https://github.com/bytecodealliance/wasmtime/issues/2432. Please note that the hex-ifying of the assertion expressions and Wasm values is pretty confusing: scalars are shown as big endian whereas vectors are shown as little endian (I tried to describe why in the comments). I would appreciate a careful look to ensure I did this correctly and any suggestions to reduce the verbosity would be great!
abrown requested alexcrichton for a review on PR #2475.
abrown updated PR #2475 from fix-1681
to main
:
This should be helpful as we investigate https://github.com/bytecodealliance/wasmtime/issues/2432. Please note that the hex-ifying of the assertion expressions and Wasm values is pretty confusing: scalars are shown as big endian whereas vectors are shown as little endian (I tried to describe why in the comments). I would appreciate a careful look to ensure I did this correctly and any suggestions to reduce the verbosity would be great!
alexcrichton submitted PR Review.
alexcrichton submitted PR Review.
alexcrichton created PR Review Comment:
If you want to get super fancy this can all get squashed into:
format!("{1:#00$x}", size_of_val(&bits) + 2, bits)
alexcrichton created PR Review Comment:
Insteaad of
reverse_pattern
could this useto_le_bytes()
as well?
abrown submitted PR Review.
abrown created PR Review Comment:
Unfortunately, no. Because the float patterns are enums of either a canonical NaN pattern, an arithmetic NaN pattern (where the payload bits are unspecified), and an actual value, I emit special hex strings for these. I can't just reverse these hex strings: I have to reverse 2-char chunks (2 hex chars per byte) and remove the leading
0x
.
abrown updated PR #2475 from fix-1681
to main
:
This should be helpful as we investigate https://github.com/bytecodealliance/wasmtime/issues/2432. Please note that the hex-ifying of the assertion expressions and Wasm values is pretty confusing: scalars are shown as big endian whereas vectors are shown as little endian (I tried to describe why in the comments). I would appreciate a careful look to ensure I did this correctly and any suggestions to reduce the verbosity would be great!
abrown submitted PR Review.
abrown created PR Review Comment:
Sorcery... done.
abrown submitted PR Review.
abrown created PR Review Comment:
@uweigand, as an FYI: I've tried to avoid this type of endianness-aware code but I didn't really know how to do this otherwise. If there is something we can do as a part of https://github.com/bytecodealliance/wasmtime/issues/2124 let me know.
abrown updated PR #2475 from fix-1681
to main
:
This should be helpful as we investigate https://github.com/bytecodealliance/wasmtime/issues/2432. Please note that the hex-ifying of the assertion expressions and Wasm values is pretty confusing: scalars are shown as big endian whereas vectors are shown as little endian (I tried to describe why in the comments). I would appreciate a careful look to ensure I did this correctly and any suggestions to reduce the verbosity would be great!
abrown merged PR #2475.
uweigand submitted PR Review.
uweigand created PR Review Comment:
@abrown Thanks for the ping! I believe your currrent code here is fine for both little- and big-endian host systems: the way V128 constants are formed should be the same on both as far as I can see (little-endian lane order and little-endian byte order within each lane).
#2124 is only relevant where it's about implementing v128.load and so on. This is not currently part of my #2124 patch because I do not yet have any SIMD support on IBM Z; I'll have a look later.
Last updated: Nov 22 2024 at 17:03 UTC