[browser][coreCLR] R2R: Enable PGO instrumentation for the WASM RyuJIT

# Enable PGO instrumentation for the WASM RyuJIT

Part of #130524.

Status: **draft / issue candidate** · Area: CoreCLR JIT, PGO, WASM build · Related: #130517 (interpreter PGO producer)

## Goal

Bring the full dynamic-profile (PGO) subsystem online for the WebAssembly RyuJIT target, so the JIT on WASM can both **produce** and **consume** profile data at parity with the desktop runtime. This is the follow-up that removes the platform limitation #130517 works around, and it is the general enabler for profile-guided precompilation and codegen on WASM.

Because dev-loop/Debug app uses R2R images from runtime pack, this feature would only supported for `publish`.

## Why

PGO (and tiered compilation) are currently disabled for the browser/WASM build, so the shared profile subsystem and the JIT's profiling entry points are absent or stubbed there. As long as that is the case, only a narrow interpreter-only producer (#130517) is possible, and the JIT cannot participate in profiling at all. Enabling the feature is the difference between a one-off prototype path and durable, first-class PGO support on WASM.

## Direction

- **Turn on the profile feature for the WASM build** so the shared profile subsystem exists and the JIT's instrumentation and consumption paths are live rather than stubbed.
- **Decouple profiling from tiered compilation on WASM.** Tiered compilation is off for this target, and the existing profiling path assumes tiering eligibility. PGO must work without that assumption — either by separating the two concerns or by providing a WASM-appropriate trigger for collecting and applying profiles.
- **Validate produce-and-consume on WASM.** Confirm the JIT can emit instrumented code, that counts flow into the shared representation, and that a collected profile is read back to guide optimized precompilation/codegen — the same round trip the desktop runtime supports.

## Scope

**In:** enabling the profile feature in the WASM build configuration; reconciling profiling with the tiering-off reality on WASM; validating the JIT produce/consume round trip on WASM.

**Out:** interpreter-side counting (that is #130517); precompiled-code packaging and loading; profile-export transport specifics.

## Success criteria

- The WASM RyuJIT produces and consumes profile data equivalently to the desktop runtime.
- The two producers — the interpreter (#130517) and the JIT — emit the same profile format, so downstream tooling is identical regardless of source.
- The enabled configuration is a supported, tested build shape, not a one-off.

## Dependencies & relationship to #130517

- **Complements #130517.** The interpreter producer can run even before this feature is fully on; this work makes the whole feature first-class. Together they settle the "how do we get PGO on WASM" decision: interpreter-only subset now (#130517), full JIT enablement as the durable follow-up (this work).
- Sequencing: #130517 can proceed against a minimal/interim subset; this work should land to make that producer sit on the same supported foundation the JIT uses.

## Open questions

- Is profiling-without-tiered-compilation a supported and tested configuration, and what work is needed to make it one on WASM?
- Build-size and complexity cost of enabling the feature for WASM, and whether any of it should be opt-in.
- Any WASM-specific gaps in emitting instrumented code or in reading profiles back for codegen.

> [!NOTE]
> This issue was drafted with GitHub Copilot assistance.