JIT: allow stack allocation of R2R arrays allocated with explicit-type helpers

[lewing]

Object stack allocation skips every array allocation in ReadyToRun code because CORINFO_HELP_READYTORUN_NEWARR_1 has no type argument for the stack allocation expansion. Some R2R code allocates arrays through the explicit-type newarr helpers instead (CORINFO_HELP_NEWARR_1_DIRECT(type, length), as in JIT-compiled code). That happens on WebAssembly, where crossgen2 does not use the compact R2R helpers. Those allocations take the same path as JIT-compiled code, so there is no reason to exclude them.

This change:

• classifies the explicit-type newarr helpers as array candidates in R2R as well, and leaves CORINFO_HELP_READYTORUN_NEWARR_1 unlisted;
• removes the blanket R2R bail-out in MorphAllocObjNodeHelperArr, which only the explicit-type helpers can now reach, and the now-unused m_isR2R.

This is the explicit-type-helper subset of #116651. Unlike #116651, it doesn't embed a class handle, so it doesn't depend on #116808. When #116651 lands, it supersedes this change.

Validation

SuperPMI asmdiffs (Checked). No asm diffs on osx-arm64 (all collections) or on linux-x64 libraries.crossgen2. Some R2R contexts replay with missing data, for example 43 of 286,981 on linux-x64 libraries.crossgen2. These are shared-generic (__Canon) array allocations that now query the array layout, GetChildType, before being rejected.

To see what those contexts compile to, I crossgen'd 9 framework assemblies for linux-x64 with matched base and diff JITs and JitDisasm: CoreLib, System.Linq, System.Linq.Parallel, System.Collections, System.Collections.Concurrent, System.Collections.Immutable, System.Text.Json, System.Private.Xml, and System.Text.RegularExpressions. Both JITs produced zero stack-allocated arrays, so native R2R codegen does not change.

JIT tests. src/tests/build.sh -Test JIT/opt/JIT.opt.csproj arm64 checked, then the merged runner:

• JIT mode: 428/428 passed.
• RunCrossGen2=1: 428/428 passed.

Wasm (browser, CoreCLR R2R, node).

• JIT/opt/ObjectStackAllocation/ObjectStackAllocationTests had its xunit attributes stripped and ran as an app, because browser CoreCLR runtime tests don't run it ([browser][coreCLR] Track disabled OOP runtime tests pending browser support #131321).
  • Before: 31/40 pass. The 9 failures are the array cases: AllocateArrayWithNonGCElements, AllocateArrayWithGCElements, AllocateArrayT<int>, AllocateArrayT<string>, SpanCaptureArray1/2, SpanCaptureArrayT<int>, SpanCaptureArrayT<string>, and StructReferredObjects.
  • After: 40/40 with both composite and non-composite publishing.
• Microbenchmark (composite, best of 15), new int[4] that doesn't escape, ×1e7: 194 ms → 27.3 ms. For comparison, native arm64 R2R is 32 ms and Tier1 is 9.4 ms. Other kernels and the framework size are unchanged.

Test exclusions. I checked whether this change lets any disabled test be re-enabled. It doesn't:

• ObjectStackAllocationTests sets <CrossGenTest>false</CrossGenTest> (Crossgen outerloop regression: JIT/opt/ObjectStackAllocation/ObjectStackAllocationTests/ObjectStackAllocationTests.cmd #109314). Native R2R allocates arrays with CORINFO_HELP_READYTORUN_NEWARR_1, which this change still skips, so that exclusion still applies.
• It sets CLRTestTargetUnsupported for browser CoreCLR ([browser][coreCLR] Track disabled OOP runtime tests pending browser support #131321). Browser CoreCLR runtime tests run on the interpreter, not R2R, so that still applies.
• On WASI it is not excluded, but out-of-process tests do not run there (OutOfProcessTest treats WASI as unsupported), so it reports as passed without executing. This holds in the composite R2R lane too.
• No other tests are gated on wasm R2R array stack allocation.

Related: #116651, #116808, #109314, #134428 (write barriers for stores into stack-allocated reference arrays).

Note

This PR description was drafted with GitHub Copilot.

[azure-pipelines]

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

[dotnet-policy-service]

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