Wasmtime GitHub notifications bot (Sep 03 2025 at 17:44): Wasmtime GitHub notifications bot (Sep 03 2025 at 17:44):alexcrichton opened PR #11597 from alexcrichton:fix-pulley-big-endian to bytecodealliance:main:
This commit fixes an issue for Pulley on big-endian targets where if a call's result was mapped to a spillslot it was loaded with a too-wide load when moving from the return location to the storage location. This only affects the shared
CallInfo::emit_retval_loadsimplementation which is unused on s390x. All other targets, with the exception of big-endian Pulley targets, using this are little-endian where the width won't matter since slots are always integer-register-in-size.The fix here is to perform a load with the exact type of the return value as opposed to a full machine word width. This fixes the big-endian behavior for Pulley and fixes the attached test cases which reproduce the issue. I've also expanded some of the many-results tests to also have many parameters to try to exercise more parts of the ABI pipeline too.
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Sep 03 2025 at 17:44):alexcrichton requested wasmtime-compiler-reviewers for a review on PR #11597.
Wasmtime GitHub notifications bot (Sep 03 2025 at 17:44):alexcrichton requested wasmtime-core-reviewers for a review on PR #11597.
Wasmtime GitHub notifications bot (Sep 03 2025 at 17:44):alexcrichton requested fitzgen for a review on PR #11597.
Wasmtime GitHub notifications bot (Sep 03 2025 at 17:56):cfallin submitted PR review:
Thanks!
Wasmtime GitHub notifications bot (Sep 03 2025 at 17:59):alexcrichton updated PR #11597.
Wasmtime GitHub notifications bot (Sep 03 2025 at 17:59):alexcrichton has enabled auto merge for PR #11597.
Wasmtime GitHub notifications bot (Sep 03 2025 at 20:02):alexcrichton updated PR #11597.
Wasmtime GitHub notifications bot (Sep 03 2025 at 20:02):alexcrichton updated PR #11597.
Wasmtime GitHub notifications bot (Sep 03 2025 at 20:08):alexcrichton updated PR #11597.
Wasmtime GitHub notifications bot (Sep 03 2025 at 20:32):alexcrichton commented on PR #11597:
@cfallin mind taking another look at this? The fix was a bit more involved than originally planned:
- I had to be a bit more clever about the loaded type than just passing
*tyto handle all the various cases correctly.- The new test added turns out to segfault on
s390xon main (before this PR, so preexisting issue) so I've flagged s390x as not implementing the exceptions proposal for now while https://github.com/bytecodealliance/wasmtime/issues/11602 is sorted out
Wasmtime GitHub notifications bot (Sep 03 2025 at 21:39):cfallin created PR review comment:
This whole expression could be wrapped up in a
Type::int_for_size(bytes: usize)helper, probably? (And IMHO the if-else split is a little clearer as something likeType::int_for_size(cmp::min(M::word_bytes(), ty.bytes())); maybe together with renamingload_tytoone_part_load_tyto make it clear why we clamp it)
Wasmtime GitHub notifications bot (Sep 03 2025 at 21:39):cfallin submitted PR review:
Updates look good; thanks for the care with the details here!
Wasmtime GitHub notifications bot (Sep 03 2025 at 23:44):github-actions[bot] commented on PR #11597:
Label Messager: wasmtime:config
It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:
[ ] If you added a new
Configmethod, you wrote extensive documentation for
it.<details>
Our documentation should be of the following form:
```text
Short, simple summary sentence.More details. These details can be multiple paragraphs. There should be
information about not just the method, but its parameters and results as
well.Is this method fallible? If so, when can it return an error?
Can this method panic? If so, when does it panic?
Example
Optional example here.
```</details>
[ ] If you added a new
Configmethod, or modified an existing one, you
ensured that this configuration is exercised by the fuzz targets.<details>
For example, if you expose a new strategy for allocating the next instance
slot inside the pooling allocator, you should ensure that at least one of our
fuzz targets exercises that new strategy.Often, all that is required of you is to ensure that there is a knob for this
configuration option in [wasmtime_fuzzing::Config][fuzzing-config] (or one
of its nestedstructs).Rarely, this may require authoring a new fuzz target to specifically test this
configuration. See [our docs on fuzzing][fuzzing-docs] for more details.</details>
[ ] If you are enabling a configuration option by default, make sure that it
has been fuzzed for at least two weeks before turning it on by default.[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html
<details>
To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.
To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.</details>
Wasmtime GitHub notifications bot (Sep 04 2025 at 01:52):alexcrichton updated PR #11597.
Wasmtime GitHub notifications bot (Sep 04 2025 at 01:52):alexcrichton updated PR #11597.
Wasmtime GitHub notifications bot (Sep 04 2025 at 01:52):alexcrichton has enabled auto merge for PR #11597.
Wasmtime GitHub notifications bot (Sep 04 2025 at 02:27):alexcrichton merged PR #11597.
Last updated: Dec 06 2025 at 06:05 UTC