[wasm] Pass Int128, Decimal128 and wide vectors by value

[lewing]

Problem

Int128/UInt128, Decimal128, Vector256<T> and Vector512<T> are passed on wasm as a single i32 pointer under the S<N> signature encoding. That is both the wrong calling convention and ambiguous.

Wrong convention. Measured against clang for wasm32 (the in-tree wasi-sdk):

type	parameter	return
__int128	2 × i64 by value	sret buffer
256-bit vector	2 × v128 by value	sret buffer
512-bit vector	4 × v128 by value	sret buffer

The returns are unaffected by -mmultivalue, and S<N> already returns through a hidden buffer, so returns are left alone. Alignment already matches clang (16/32/64) and is unchanged by this PR.

Ambiguous. S<N> resolves through a size-keyed, first-wins struct cache, so Int128 and Guid both spell S16 and share a thunk whose frame layout only fits whichever type the cache happened to see first. This reproduces as miscompiles under R2R today: Int128.Equals returns False and CompareTo returns ±1 for values that are equal.

Change

Encode such a parameter as the slot character followed by the factor its alignment is elevated above the slot's natural alignment:

encoding	alignment	types
l	8 (natural)	long
l2	16	Int128, UInt128, Decimal128
V	16 (natural)	Vector128<T>, Vector<T>
V2	32	Vector256<T>
V4	64	Vector512<T>

This stays unambiguous when mixed: ll2VV4 is i64, Int128, Vector128, Vector512. An elevation factor that differs from the slot count is not expressible; no type today needs one.

Classification is structural rather than by name — intrinsic, aligned to its own size, and wider than one slot. Each condition is load-bearing:

• intrinsic — the wasm C ABI passes an ordinary aggregate indirectly, and struct { long a, b; } decomposes exactly like Int128 but must stay indirect.
• alignment == size — excludes Vector2/3/4, which are intrinsic but 4-aligned. Alignment alone would not do, since StructLayout(Pack) can manufacture it.
• size > slot size — excludes v128 and Vector64<T> without naming them. The threshold must be the slot's own width rather than a fixed number, since Int128 needs two slots at the same 16 bytes a v128 fills with one.

Decimal128 is picked up by that rule without being named anywhere.

Three encoders have to agree exactly, since the signature string is a thunk's identity: crossgen2 (WasmLowering), the runtime (vm/wasm/helpers.cpp), and WasmAppBuilder (SignatureMapper).

An encoding records layout, not identity, so raising resolves a stand-in — l2 always raises to Int128. That is sound because a thunk is keyed by its signature string and its frame layout derives from nothing else, which the tests pin.

Interop

WasmAppBuilder reports WASM0068 for these types rather than encoding them. Supporting them means teaching the thunk generator that one signature token can map to several native parameters, which is a larger design question; no PInvoke or InternalCall signature uses one today.

Validation

Browser wasm, Release and Checked, both DOTNET_ReadyToRun=0 and =1:

check	result
Int128 equality/comparison repro	passes both arms (fails on main under R2R=1)
single-field wrapper repro	passes both arms
Vector256/Vector512/Vector64 repro	passes both arms
Microsoft.Bcl.Memory	550/550 both arms
System.Runtime.CompilerServices.Unsafe	128/128 both arms
WasmArgumentLayoutTests	47/47
full Checked build	clean, zero asserts, CoreLib crossgen'd with --verify-type-and-field-layout

Each repro was confirmed to fail without the change before being trusted as a pass, and the runtime encoder was confirmed live by perturbation (emitting the wrong slot char breaks R2R=1 with a function signature mismatch).

Notes

• Two commits: the ABI change under src/coreclr, then the interop rejection under src/tasks.
• The JIT-EE version GUID is bumped.
• Supersedes the approach in [wasm] Use ordinary struct alignment for Int128/UInt128 on wasm #131421, which changed alignment; alignment is not the problem here.

Note

This pull request was prepared with GitHub Copilot.

[dotnet-policy-service]

Tagging @dotnet/jit-contrib for JIT-EE GUID update

[azure-pipelines]

Azure Pipelines:
Successfully started running 7 pipeline(s).
9 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

This PR updates the wasm calling convention/signature encoding so certain “wide” intrinsic value types (e.g., Int128/UInt128, Vector256, Vector512, Decimal128) are passed by value across multiple wasm parameters instead of being encoded as ambiguous S<N> by-ref structs. The change spans the runtime encoder, crossgen2 lowering/raising, R2R thunk generation, and the JIT’s ABI classification so all components agree on the same signature identity and frame layout.

Changes:

• Add a multi-slot signature token form (l2, V2, V4) and use it for qualifying intrinsic wide types when passed as parameters; keep returns as S<N> (retbuf).
• Update runtime and crossgen2 signature lowering/raising and R2R thunk emitters to correctly marshal multi-slot arguments.
• Add/extend unit tests and update the ready-to-run format documentation; reject multi-slot types in WasmAppBuilder interop signatures.

Reviewed changes

Copilot reviewed 17 out of 17 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/tasks/WasmAppBuilder/coreclr/SignatureMapper.cs	Reject multi-slot ABI types for interop signatures; parse multi-slot tokens.
src/coreclr/vm/wasm/helpers.cpp	Runtime signature encoding supports multi-slot parameter tokens and preserves return behavior.
src/coreclr/tools/Common/JitInterface/WasmLowering.cs	Crossgen2 lowering/raising now classifies and encodes multi-slot parameters and separates return-struct caching.
src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs	Exposes multi-slot slot-type lowering to the JIT via getWasmLowering.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.Wasm.cs	Adds elevated-type resolution and a separate cache for return structs to keep raising stable/unambiguous.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/WasmLowering.ReadyToRun.cs	Ensures multi-slot types are treated as by-value (not byref) in R2R paths.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/WasmR2RToInterpreterThunkNode.cs	Stores multi-slot wasm locals into the interpreter argument area slot-by-slot.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/WasmInterpreterToR2RThunkNode.cs	Loads multi-slot arguments from interpreter arg area and forwards each slot as a wasm parameter.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/WasmImportThunk.cs	Stashes/restores multi-slot arguments as multiple locals during import thunk transitions.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/WasmArgumentLayoutTests.cs	Adds coverage for multi-slot encoding, raising stability, cache poisoning avoidance, and Decimal128 shape.
src/coreclr/jit/targetwasm.cpp	Splits struct args into multiple wasm “register” segments when size exceeds the lowered wasm value width.
src/coreclr/jit/lower.cpp	Adjusts FieldList/PutArg marking logic for targets without fixed register sets (wasm).
src/coreclr/jit/compiler.cpp	Forces multi-slot returns to use retbuf (byref) while allowing multi-slot passing.
src/coreclr/jit/codegenwasm.cpp / src/coreclr/jit/codegen.h	Consumes FIELD_LIST args per-field for correct liveness on wasm (no PUTARG nodes).
src/coreclr/inc/jiteeversionguid.h	Bumps JIT/EE interface GUID.
docs/design/coreclr/botr/readytorun-format.md	Documents the multi-slot token grammar and examples.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

src/coreclr/tools/Common/JitInterface/WasmLowering.cs:689

• sigBuilder.Append(slotCount); will append multi-digit numbers (e.g., 10) if slotCount ever exceeds 9, which would make the signature ambiguous/misparsed (RaiseSignature only consumes a single digit). Prefer emitting a single digit char and assert the supported range so malformed signatures fail fast.

                    if (TryGetMultiSegmentLayout(paramType, out WasmValueType slotType, out int slotCount))
                    {
                        // Passed by value across several wasm parameters, matching the wasm C ABI.
                        // Spelled '<slot><elevation>'; the elevation factor equals the slot count
                        // for every type in the wasm ABI today, and the encoding cannot express
                        // them differing. See readytorun-format.md.
                        sigBuilder.Append(WasmValueTypeToSigChar(slotType));
                        sigBuilder.Append(slotCount);
                        for (int slot = 0; slot < slotCount; slot++)
                        {
                            result.Add(slotType);

[lewing]

cc @dotnet/wasm-contrib

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

src/tasks/WasmAppBuilder/coreclr/SignatureMapper.cs:186

• The wrapper-unwrapping heuristic in IsMultiSlotType assumes “a single field fills its struct unless the struct declares a size”, but that’s not true for explicit-layout wrappers with a non-zero FieldOffset. Those can be larger than the field without setting StructLayoutAttribute.Size, and unwrapping them here can cause over-rejection (treating an indirect struct as multi-slot). Consider checking for explicit non-zero field offsets and avoiding unwrapping in that case (still keeping the explicit Size check).

            // Only unwrap a wrapper its field fills exactly. Sizes cannot be measured here: these
            // types come from a MetadataLoadContext, where Marshal.SizeOf always throws. A single
            // field fills its struct unless the struct declares a size of its own.
            FieldInfo[] fields = t.GetFields(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);
            if (fields.Length != 1 || t.StructLayoutAttribute is { Size: not 0 })
            {
                return false;
            }

src/coreclr/vm/wasm/helpers.cpp:1020

• ConvertType::ToSlotsI64 is now also used for Decimal128 (it shares the l2 encoding), but the comment only mentions Int128/UInt128. Updating the comment would help keep the three encoders’ intent aligned while debugging ABI classification.

        ToSlotsI64,  // Passed by value as several i64 slots (Int128/UInt128)
        ToSlotsV128, // Passed by value as several v128 slots (Vector256<T>, Vector512<T>)

[azure-pipelines]

Azure Pipelines:
Successfully started running 7 pipeline(s).
9 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[AndyAyersMS]

JIT changes look good, the rest looks reasonable, but I'll defer to @davidwrighton for those.

[AndyAyersMS]

The JIT is currently not able to support any alignment beyond 16 bytes.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

src/coreclr/tools/Common/JitInterface/WasmLowering.cs:688

• The multi-slot encoding is documented (and parsed in RaiseSignature / WasmAppBuilder) as a single digit elevation factor, but here sigBuilder.Append(slotCount) will emit multiple characters when slotCount >= 10, producing a signature string that RaiseSignature cannot round-trip (it only consumes one digit) and that would be ambiguous in the overall grammar. Since the encoding can only represent a single digit, this should append a single digit char and assert the supported range (matching the runtime encoder’s slotCount <= 9 invariant).

                        // Passed by value across several wasm parameters, matching the wasm C ABI.
                        // Spelled '<slot><elevation>'; the elevation factor equals the slot count
                        // for every type in the wasm ABI today, and the encoding cannot express
                        // them differing. See readytorun-format.md.
                        sigBuilder.Append(WasmValueTypeToSigChar(slotType));
                        sigBuilder.Append(slotCount);
                        for (int slot = 0; slot < slotCount; slot++)
                        {
                            result.Add(slotType);
                        }

src/tasks/WasmAppBuilder/coreclr/SignatureMapper.cs:186

• The wrapper-unwrapping heuristic (fields.Length == 1 and no explicit StructLayoutAttribute.Size) can misclassify explicit-layout wrappers. For example, an explicit-layout struct with a single field at a non-zero FieldOffset (or other layout-induced padding) does not satisfy the “field fills struct exactly” rule that the runtime / crossgen2 use (they both compare the field size to the struct size). Since WasmAppBuilder can’t measure size for MetadataLoadContext types, it should conservatively refuse to unwrap explicit-layout / FieldOffset wrappers to avoid rejecting otherwise-valid interop signatures or incorrectly tagging them as multi-slot.

            // Only unwrap a wrapper its field fills exactly. Sizes cannot be measured here: these
            // types come from a MetadataLoadContext, where Marshal.SizeOf always throws. A single
            // field fills its struct unless the struct declares a size of its own.
            FieldInfo[] fields = t.GetFields(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);
            if (fields.Length != 1 || t.StructLayoutAttribute is { Size: not 0 })
            {
                return false;
            }