[wasm R2R] Align 8-byte stack locals and keep frames 16-aligned

[AndyAyersMS]

Fixes #129802.

Problem

On the WebAssembly CoreCLR + ReadyToRun (crossgen2-wasm) configuration, 64-bit
JS interop values (long/BigInt, double, DateTime, Int52) were corrupted
crossing the managed↔JS boundary: corrupted = (original & 0xFFFFFFFF) << 32. The JS
side reads/writes these slots through the 8-byte HEAP64/HEAPF64 typed-array views
(addr >>> 3), which require 8-byte alignment; the marshaler buffer was landing at a
4-mod-8 address, so the view addressed the wrong word.

Root cause

wasm is TARGET_WASM32 (4-byte pointers) and does not define TARGET_64BIT, so:

• The per-local 8-byte alignment padding in lvaAllocLocalAndSetVirtualOffset was gated
  on TARGET_64BIT and compiled out, leaving 8-byte stack locals only 4-byte aligned.
• lvaAlignFrame was a no-op for wasm, so the frame size was only 4-byte aligned. Since
  the shadow stack pointer is threaded through calls (calleeSP = callerSP - frameSize),
  a single 4-mod-8-sized frame drifts every deeper frame — and every stackalloc'd
  marshaler buffer — out of 8-byte alignment.

Fix

• Enable the existing 8-byte-local alignment for TARGET_WASM.
• Round compLclFrameSize up to STACK_ALIGN in lvaAlignFrame for wasm so the shadow
  SP stays aligned across calls.

Validation

• The wasm cross-JIT rebuilds clean.
• crossgen2-wasm JitDump of a method with the marshaler pattern (address-taken long +
  stackalloc Span) confirms every 8-byte local now lands at an 8-aligned frame offset
  and the frame size is a multiple of 16 (the Pad … size=8 events only fire from the
  newly enabled code block).
• A JSImport BigInt/double echo repro passes on the interpreter (matching the
  issue's interpreter baseline).

A black-box R2R pass/fail is best covered by the existing
System.Runtime.InteropServices.JavaScript.UnitTests suite on the coreclr-wasm-R2R lane.

Note

This PR was generated with the assistance of GitHub Copilot and reviewed before posting.

[Copilot]

Pull request overview

This PR updates CoreCLR JIT frame layout for WebAssembly targets to ensure (a) stack locals requiring 8-byte alignment are actually 8-byte aligned, and (b) the overall frame size stays aligned to STACK_ALIGN so alignment doesn’t drift across nested calls.

Changes:

• Enable the existing “align >=8-byte locals” padding logic for TARGET_WASM in lvaAllocLocalAndSetVirtualOffset.
• Implement TARGET_WASM frame-size alignment in lvaAlignFrame by rounding compLclFrameSize up to STACK_ALIGN (and reserving worst-case padding during non-final layout passes).

[AndyAyersMS]

@pavelsavara I can't fully validate this, so give it a try if you can.

@adamperlin PTAL
fyi @dotnet/wasm-contrib

[pavelsavara]

🎉

[pavelsavara]

thanks

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.