Gelbpunkt opened PR #14770 from Gelbpunkt:s390x-128bit-atomic-load-store to bytecodealliance:main:
Since we store I128 in vector registers, we perform loads into vector registers and use vector stores to implement atomic store.
This was suggested by @theotherjimmy in yesterday's Cranelift meeting (thanks!).
I've verified that the atomic load/store part of the atomic-128 runtest passes on s390x in qemu-user and on z15 in a z/VM environment, but since the atomic-128 runtest also requires
atomic_cas(which I have implemented and will PR as a follow-up) andatomic_rmw(WIP), it cannot be enabled on s390x yet.
Gelbpunkt requested wasmtime-compiler-s390x-reviewers for a review on PR #14770.
Gelbpunkt requested alexcrichton for a review on PR #14770.
Gelbpunkt requested wasmtime-compiler-reviewers for a review on PR #14770.
Gelbpunkt edited PR #14770:
Since we store I128 in vector registers, we perform loads into vector registers and use vector stores to implement atomic store. This is different from the other backends, which use "regular" atomic load and store instructions from GPRs, which also exist on s390x in the form of
LPQandSTPQ. However, s390x differs from the other supported ISAs: its ABI mandates that i128 must be passed indirectly rather than in a pair of GPRs. Using the value of an i128 parameter will generate a load of the value from memory viagen_load(and analogous forgen_storewhen an i128 is returned), which only gets oneRegto generate the load into - and it will only fit in a VR. Therefore, it makes sense to always keep our i128s in VRs. This also makes sense foratomic_rmwlater, where vector operations will generally let us perform the modifications more efficiently than on pairs of GPRs. Therefore, we keep our i128s in vector registers and only move them to GPRs when absolutely necessary (e.g. forCDSG).This was suggested by @theotherjimmy in yesterday's Cranelift meeting (thanks!).
I've verified that the atomic load/store part of the atomic-128 runtest passes on s390x in qemu-user and on z15 in a z/VM environment, but since the atomic-128 runtest also requires
atomic_cas(which I have implemented and will PR as a follow-up) andatomic_rmw(WIP), it cannot be enabled on s390x yet.
:thumbs_up: theotherjimmy submitted PR review.
:thumbs_up: alexcrichton submitted PR review.
alexcrichton added PR #14770 cranelift: Implement 128-bit big-endian atomic load/store for s390x to the merge queue.
:repeat: uweigand submitted PR review:
Needs a fix to avoid incorrect little-endian stores.
(We could implement little-endian stores easily on z15 and later, but on z14 we'd probably have to use a vector permute.)
:speech_balloon: uweigand created PR review comment:
This is only correct for big-endian stores, so it should have the same check as above.
:memo: Gelbpunkt submitted PR review.
:speech_balloon: Gelbpunkt created PR review comment:
Ah, good point. I overlooked this because
istore64_impltakes care of handling it
Gelbpunkt updated PR #14770.
:memo: Gelbpunkt submitted PR review.
:speech_balloon: Gelbpunkt created PR review comment:
Fixed!
alexcrichton removed PR #14770 cranelift: Implement 128-bit big-endian atomic load/store for s390x from the merge queue.
alexcrichton has enabled auto merge for PR #14770.
:thumbs_up: uweigand submitted PR review:
LGTM now, thanks!
alexcrichton added PR #14770 cranelift: Implement 128-bit big-endian atomic load/store for s390x to the merge queue.
:check: alexcrichton merged PR #14770.
alexcrichton removed PR #14770 cranelift: Implement 128-bit big-endian atomic load/store for s390x from the merge queue.
Last updated: Oct 31 2026 at 23:03 UTC