cfallin requested fitzgen for a review on PR #10863.
cfallin opened PR #10863 from cfallin:big-endian-is-just-too-big-for-some-cpus to bytecodealliance:main:
At some point during the development of the Cranelift backend infrastructure, to properly support big-endian architectures such as s390x, we added explicit endianness flags to
MemFlags, which are given to all memory operations (e.g., loads, stores, and atomic ops). In s390x in particular, the backend carefully observes these flags, because a prominent use of Cranelift (as a Wasm backend) requires explicit little-endian behavior and the system is big-endian. However, all of our other supported ISAs are little-endian and so we did not implement explicit checks at the time, instead accepting all loads and stores as an artifact of our little-endian-only origins.This PR adds explicit conditions to all ISLE rules that lower loads, stores, and atomic ops on x86-64, aarch64, and riscv64 to accept little or "native" (also little) endian operations only. Compilation of a big-endian operation will now result in a compilation error because no ISLE rule will match (no lowering exists). At some later point we could add these lowerings, but for now we at least do not miscompile.
Fixes #10861.
<!--
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
-->
cfallin requested wasmtime-compiler-reviewers for a review on PR #10863.
cfallin commented on PR #10863:
(Note that the Pulley backend rules appear to have explicit consideration for endianness, so I skipped that backend here.)
cfallin commented on PR #10863:
Design note: I could have added checks to more central places in all three backends instead -- namely,
Amodeconstruction -- but opted instead to annotate every rule with this predicate, because the information logically belongs to the individual lowerings and if we want to add actual big-endian lowerings in the future, we'll wantAmodeto work for those too.
fitzgen submitted PR review.
fitzgen merged PR #10863.
Last updated: Dec 06 2025 at 06:05 UTC