Stream: git-wasmtime

Topic: wasmtime / issue #10852 Cranelift: Little/Big endian has ...

Wasmtime GitHub notifications bot (May 28 2025 at 13:34):

songtianlei opened issue #10852:

.clif Test Case

test optimize
    set opt_level=none
    set preserve_frame_pointers=true
    set enable_multi_ret_implicit_sret=true
    target s390x

function %main() -> i64, i64 , i16x8 fast {
    ss0 = explicit_slot 32

block0:
    v1 = iconst.i64 0x0011_0022_0033_0044
    stack_store v1, ss0
    stack_store v1, ss0+8
    stack_store v1, ss0+16
    stack_store v1, ss0+24

    v80 = stack_addr.i64 ss0
    v81 = load.i64 big v80
    v82 = sload8x8 big v80
    return v80, v81, v82
}

; print: %main()

Description

When I specify the load and sload8x8 instructions as big-endian

v81 = load.i64 big v80
v82 = sload8x8 big v80

the execution results are as follows.

%main() -> [274928428480, 4785220636311620, 0x00440000003300000022000000110000]

Then I changed them to little-endian, and the results are as follows.

v81 = load.i64 little v80
v82 = sload8x8 little v80

%main() -> [274928428480, 4899972470242545920, 0x00440000003300000022000000110000]

The value of v81 changed, which is expected. But the value of v82 stayed the same, indicating that little/big-endian has no effect on sload8x8.

Environment

qemu-s390x to emulate execution on an x86 machine.

Wasmtime GitHub notifications bot (May 28 2025 at 13:34):

songtianlei added the bug label to Issue #10852.

Wasmtime GitHub notifications bot (May 28 2025 at 13:34):

songtianlei added the cranelift label to Issue #10852.

Wasmtime GitHub notifications bot (May 28 2025 at 14:48):

alexcrichton added the cranelift:area:s390x label to Issue #10852.

Wasmtime GitHub notifications bot (May 28 2025 at 14:48):

alexcrichton commented on issue #10852:

cc @uweigand

Wasmtime GitHub notifications bot (May 28 2025 at 15:06):

uweigand commented on issue #10852:

There should be no effect - an array (or vector) of 8 single-byte elements has the same in-memory representation on both big-endian and little-endian systems.

Wasmtime GitHub notifications bot (May 28 2025 at 15:12):

alexcrichton closed issue #10852:

.clif Test Case

test optimize
    set opt_level=none
    set preserve_frame_pointers=true
    set enable_multi_ret_implicit_sret=true
    target s390x

function %main() -> i64, i64 , i16x8 fast {
    ss0 = explicit_slot 32

block0:
    v1 = iconst.i64 0x0011_0022_0033_0044
    stack_store v1, ss0
    stack_store v1, ss0+8
    stack_store v1, ss0+16
    stack_store v1, ss0+24

    v80 = stack_addr.i64 ss0
    v81 = load.i64 big v80
    v82 = sload8x8 big v80
    return v80, v81, v82
}

; print: %main()

Description

When I specify the load and sload8x8 instructions as big-endian

v81 = load.i64 big v80
v82 = sload8x8 big v80

the execution results are as follows.

%main() -> [274928428480, 4785220636311620, 0x00440000003300000022000000110000]

Then I changed them to little-endian, and the results are as follows.

v81 = load.i64 little v80
v82 = sload8x8 little v80

%main() -> [274928428480, 4899972470242545920, 0x00440000003300000022000000110000]

The value of v81 changed, which is expected. But the value of v82 stayed the same, indicating that little/big-endian has no effect on sload8x8.

Environment

qemu-s390x to emulate execution on an x86 machine.

Wasmtime GitHub notifications bot (May 28 2025 at 15:12):

alexcrichton commented on issue #10852:

Oops yes indeed! I'll close this as "working as intended", but @songtianlei if you have follow-up questions please feel free to post them here too.

Wasmtime GitHub notifications bot (May 29 2025 at 09:08):

songtianlei commented on issue #10852:

@alexcrichton @uweigand
I also noticed that sload behaves differently on x86 and s390x when using little or big endian.

.clif Test Case

test optimize
    set opt_level=none
    set preserve_frame_pointers=true
    set enable_multi_ret_implicit_sret=true

function %main() -> i64 fast {
    ss0 = explicit_slot 32

block0:
    v1 = iconst.i64 0x0011_0022_0033_0044
    stack_store v1, ss0
    stack_store v1, ss0+8
    stack_store v1, ss0+16
    stack_store v1, ss0+24

    v80 = stack_addr.i64 ss0
    v81 = sload32 little v80
    return v81
}
; print: %main()

The sload instruction is set to little-endian and run on both x86 and s390x.

v81 = sload32 little v80

The reslut:

[x86  ]%main() -> 3342404
[s390x]%main() -> 570429696

Then changed it to big-endian.

v81 = sload32 big v80

[x86  ]%main() -> 3342404
[s390x]%main() -> 1114146

Why does the result change on s390x but stay the same on x86?

Wasmtime GitHub notifications bot (May 29 2025 at 09:20):

bjorn3 commented on issue #10852:

stack_store instructions are always using the native endian, so s390x and x86_64 have different data on the stack in your example, so using a fixed endianness for the load still results in different values.

Wasmtime GitHub notifications bot (May 29 2025 at 10:42):

songtianlei commented on issue #10852:

I know the stack data is different. I'm not asking why s390x and x86 give different results. My point is: when I switch between little and big endian, sload gives different results on s390x, but on x86, both cases produce the same result.

Wasmtime GitHub notifications bot (May 29 2025 at 10:52):

bjorn3 commented on issue #10852:

Right. I think the reason is that the s390x backend is the only one that supports endianness flags. It is the only architecture Cranelift supports where the wasm and native endianness are different. For all other architectures both Wasmtime and rustc_codegen_cranelift agree on which endianness to use, so probably nobody bothered to actually add big-endian support.

Wasmtime GitHub notifications bot (May 29 2025 at 14:01):

songtianlei commented on issue #10852:

Thank you very much for your detailed answer.

Wasmtime GitHub notifications bot (May 29 2025 at 14:03):

songtianlei deleted a comment on issue #10852:

Thank you very much for your detailed answer.

Wasmtime GitHub notifications bot (May 29 2025 at 14:04):

songtianlei commented on issue #10852:

@bjorn3 Thank you very much for your detailed answer.

Wasmtime GitHub notifications bot (May 29 2025 at 15:25):

bjorn3 commented on issue #10852:

Opened https://github.com/bytecodealliance/wasmtime/issues/10861 to track either implementing or emitting an error for the big-endian flag on little-endian targets.

Last updated: Dec 06 2025 at 06:05 UTC