wasm `u128`/`i128` is improperly aligned

[V0ldek]

The u128 and i128 types on the wasm targets has alignment of 8. This is inconsistent with the alignment on all Tier-1 targets.

Compile this code:

#![crate_type = "cdylib"]
#[no_mangle]
pub extern "C" fn align_of_u128() -> usize {
    std::mem::align_of::<u128>()
}

Godbolt link.

The body of this function on all Tier-1 targets is "return 16", while on wasm32-unknown-unknown, wasm32-unknown-emscripten, and wasm32-wasi it compiles to "return 8".

This causes arrays that are aligned on wasm to no longer be aligned when pointers are passed through FFI to the host. For example, creating a Vec<u128> in wasm and returning it as slice to the host causes misalignment.

I am not sure if this is a compiler bug or if this is for some reason intentional, but it is very annoying. A workaround is to declare your own this wrapper to force alignment and use it throughout:

#[repr(C, align(16))]
struct au128(u128);

however that doesn't play well with external libraries that use u128.

Meta

This happens both on stable 1.83 (see the Godbolt link above) and my nightly from 2024-12-05

rustc --version --verbose:

rustc 1.85.0-nightly (c94848c04 2024-12-05)
binary: rustc
commit-hash: c94848c046d29f9a80c09aae758e27e418a289f2
commit-date: 2024-12-05
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.5

[hanna-kruppe]

Quite a few non-wasm targets have eight byte alignment for u128 and i128 (e.g., 32-bit Arm and RISC-V targets). I don't know of any that are tier 1 right now, but tiers can change over time, tier 1 is a very high bar, and many tier 2 targets are widely used. In fact, some tier 1 targets had 8-byte-aligned u128 until earlier this year. So I would strongly advice against assuming any particular alignment for those types.

That said, in general i128 and u128 should be interoperable with C's 128-bit integer types when they exist. I don't know when Clang started supporting these types in wasm, but WebAssembly/tool-conventions#240 indicates that they're supported now with 16 byte alignment. So Rust may have to increase the alignment of these types on the wasm targets anyway for interop with C code that's also compiled to wasm. That doesn't change the fact that non-wasm code shouldn't assume it agrees with wasm code on the alignment.

A workaround is to declare your own this wrapper to force alignment and use it throughout:

Another solution is to use u128 on the wasm side but not on the host side, at least not for talking about slices pointing into wasm memory. You can avoid assuming any alignment for things in wasm memory and do unaligned reads via uN::from_le_bytes. Explicitly using little endian byte order also makes the host code portable to big endian platforms (wasm is always little-endian).

[V0ldek]

The reason I mention Tier 1 targets is that wasm is a bit "special", especially wasi, in that it often needs to interop with host functions. Different alignments between x86 and idk PowerPC are unlikely to matter, whereas wasm is by necessity embedded in another target.

[hanna-kruppe]

Sure, but the host code isn't limited to tier 1 Rust targets. As a concrete example, wasmtime explicitly supports several targets that are or were tier 2 in rustc (currently Linux s390x and Linux riscv64, also macOS aarch64 was only promoted to Rust tier 1 recently). Rust target tiers are basically never relevant for "do I need to worry about this target when writing portable code?" because the tiers don't have any inherent meaning, they only reflect how much a target is currently tested in rust-lang/rust CI.

[workingjubilee]

Yes.

We do not intend to alter our wasm ABI conformance based on non-wasm targets.

We do have to alter the alignment to match the ABI documented by tool-conventions.

[workingjubilee]

cc @sunfishcode and @alexcrichton Should this be done upstream in LLVM? Like was done in llvm/llvm-project@dbad963 for SPARC.