[browser][CoreCLR] Collect ReadyToRun PGO with indexed schemas - #137491

Design differences from #136860

This is a separate implementation on a fresh main baseline. The earlier PR remains unchanged.

The fundamental change is richer execution information, not more precise counting of every logical invocation around exceptions. Reusing JIT instrumentation avoids a separate importer-driven block profiler and accommodates multiple counters per method.

IL0 is not inherently an entry counter: it can be a loop backedge target. The consumer therefore reconstructs method-entry flow from the measured graph where possible rather than equating IL0 hotness with invocation count. Synthetic/split compiler blocks do not acquire duplicate IL-block probes.

Invocation-only records are still necessary for intrinsic expansions and coarse interpreter execution. They describe omitted-body contributions, not a fabricated complete block profile. A method may legitimately have both kinds of data; the consumer preserves measured branch information while adding invocation contributions.

Several foundations are deliberately retained: 64-bit counters, allocation-base-plus-offset addressing, the shared WasmPgoInstrumentation configuration, the existing EventPipe-to-MIBC pipeline, canonical method attribution, and independent CPU sampling. They should not be mistaken for new differences.

The initial scope remains single-threaded Browser/CoreCLR with diagnostics and original IL. It does not introduce edge probes, histogram collection, or precise exception-flow parity. Training incurs counter-update overhead; these changes do not establish an application-level consumer speedup.

Retained MIBC comparison and interpretation

Compared the latest successful Release, unfiltered PGO browser runs from the two implementations, decoding both MIBCs with the same current dotnet-pgo reader:

• Previous: November 11 run blazor_method_entry_pgo_Release_False_xkxx5sas_hr5, method-entry.mibc.
• Current: November 13 run blazor_basic_block_pgo_Release_False_bhaf03dq_apt, basic-block.mibc.

Coverage and profile size

The compressed profile grows 71.8%, principally because ordinary methods now carry multiple block records instead of one invocation record. Both files remain MIBC format 1.1: the indexed schema table changes the R2R producer's wire format, not the MIBC container format.

The current profile contains 7,471 block-only, 598 invocation-only, and 49 mixed method records, plus 81 without counters.

Method coverage is nearly unchanged. The display-name sets share 8,187 names, with 11 current-only and 22 previous-only. Each dump also has one repeated display name for a UInt128.op_Explicit overload, so display-name set counts are not the raw method-record counts.

Both have 225 Vector128/PackedSimd-related method records. This comparison does not show a new large set of SIMD roots: the improvement is richer information about already-covered algorithms. For example, Ascii.WidenAsciiToUtf1_Vector<Vector128<byte>, Vector128<ushort>> retains 723 entry-block executions, but now also exposes its internal block/loop counts and unexecuted paths.

These are representative retained runs, not a controlled same-build experiment. Main revisions, test sources, and runtime execution differ. Some set differences are explicitly new/removed scenarios; the remainder cannot all be attributed to instrumentation design. Profile candidates also do not guarantee additional standalone R2R bodies: canonical sharing, eligibility, dependencies, and inlining still determine the output.

Concrete counter differences

The new IlZeroBackedge scenario records 7 at IL0 and 1 at exit, although there was only one invocation. This is why IL0 cannot automatically be consumed as an entry count: graph flow must distinguish backedge executions from external entries.

Zero-valued body blocks now express unexecuted paths in the measured body schema, not a guess derived from entry hotness. Invocation-only contributions remain separate:

• A WebAssembly InlineArrayElementRef previously recorded 9 invocations; now it records 3 body executions + 6 omitted-body invocations.
• string.EndsWith(string, StringComparison) retains 284 invocation contributions even though its body-block allocation is zero-valued. Ignoring the invocation record would incorrectly erase that hotness.

What the consumer demonstrably changes

The retained consumer listing for EntryAndBackedge changes from Synthesized PGO to Static PGO, preserving entry count 2. The new IL0-backedge case reports Static PGO, entry count 1, rather than confusing its seven IL0 executions with seven invocations.

However, DirectCalls and GenericCalls still report Synthesized PGO in their final listings. Both retain the expected inlinees with PGO data. Richer MIBC data does not establish that every transformed method ends with a wholly measured static profile.

The practical benefit is measured loop hotness and more constrained branch-flow reconstruction instead of relying only on heuristic internal flow seeded from invocation counts. This is evidence of better profile information and consumption, not a measured application speedup or proof of complete exception/edge-profile parity.

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

Tagging subscribers to this area: @dotnet/crossgen-contrib
See info in area-owners.md if you want to be subscribed.

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

Superseded by dotnet/runtime#137502.

The branch was copied into dotnet/runtime as pavelsavara/browser-coreclr-r2r-pgo-schema-table at commit 06fa85f1de97d2fb9d49281677436b6387aba9e0. Please continue review and further changes on the replacement PR; existing discussion remains here for reference.