Wasm R2R Pri0 Validation Issues

[AndyAyersMS]

Summary

Tracking Wasm R2R Pri0 failures where Crossgen2 produces a .wasm file, but Node/WebAssembly validation rejects it when the test runner tries to construct the module.

Initial build and R2R test-run setup is described in #129497.

Validation failure buckets

Count	Wasm output	Validation error
23	TestLibrary.wasm	not enough arguments on the stack for i32.store (need 2, got 1)
3	Regression_o_3.wasm	i32.store[1] expected type i32, found call_indirect of type f32
2	Regression_o_1.wasm	not enough arguments on the stack for call_indirect (need 2, got 1)
2	Regression_ro_2.wasm	i64.shr_u[0] expected type i64, found local.get of type i32
2	Regression_PdbOnly_r_3.wasm	param count of 8194 exceeds internal limit of 1000

The repeated TestLibrary.wasm bucket appears across multiple JIT merged runners, so it may be one bad R2R'd support assembly surfacing repeatedly.

Note

This issue was created with assistance from GitHub Copilot.

[AndyAyersMS]

These are most likely codegen problems.

[AndyAyersMS]

The TestLibrary.wasm issue is a discrepancy in return type for variabled-sized object ctors like System.String(char[], int, int). The declared type of a ctor is TYP_VOID but these methods actually return TYP_REF.

There are two types on a call node, gtType and gtReturnType. Wasm codegen currently always looks at gtReturnType.

gtType tracks the physical return type, and gtReturnType the declared return type (I think). Since Wasm looks at gtReturnType, it creates a void returning Wasm sig, while the IR and codegen expects there to be a return value.

Switching to using gtType may not work in all cases (eg for fast tail calls this seeming gets bashed to TYP_VOID since those calls don't "return").

NAOT-LLVM doesn't have this issue because the string ctor gets swapped for a function with an accurate signature.

---

Seems like using gtType might work. Also fixes the Regression_o_1.wasm cases.

[AndyAyersMS]

For Regression_o_3 (Runtime_85630.cs), we have a struct-wrapped float and can't decide whether to treat it as i32 or f32 at an abi boundary.

[AndyAyersMS]

These have all been fixed.