JIT: enable stack allocation of more arrays in R2R #116651

AndyAyersMS · 2025-06-13T20:16:13Z

In particular arrays that are created via CORINFO_HELP_READYTORUN_NEWARR_1.

Also:

move inlining boost for "returns small array" to the default policy as well as the extended default policy. This addresses part of Escape Analysis: Elide an array allocation in BitConverter.GetBytes pattern #113236.
enable the stack allocation test for R2R, by marking certain methods where particular inlines are needed for non-escape that won't happen in R2R as aggressive opt.

Contributes to #104936

In particular arrays that are created via `CORINFO_HELP_READYTORUN_NEWARR_1`. Also: * move inlining boost for "returns small array" to the default policy as well as the extended default policy. This addresses part of dotnet#113236. * enable the stack allocation test for R2R, by marking certain methods where particular inlines are needed for non-escape that won't happen in R2R as aggressive opt. Fixes dotnet#109314. Contributes to dotnet#104936

dotnet-policy-service · 2025-06-13T20:17:01Z

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

Copilot

Pull Request Overview

Enables stack allocation of arrays created via the CORINFO_HELP_READYTORUN_NEWARR_1 helper, moves the inlining boost for small-array returns into the default inline policy, and re-enables the corresponding R2R stack-allocation tests.

Introduce a new allocation kind (OAT_NEWARR_R2R) and handle it in ObjectAllocator and helper expansion.
Promote the CALLEE_MAY_RETURN_SMALL_ARRAY observation into the default inline policy with a higher inline multiplier.
Remove the test exclusion for ObjectStackAllocationTests and tag test methods with AggressiveOptimization so they run under R2R.

Reviewed Changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/tests/issues.targets	Re-enable `ObjectStackAllocationTests` by removing the exclude.
src/tests/JIT/opt/ObjectStackAllocation/ObjectStackAllocationTests.cs	Added `AggressiveOptimization` to force inlining in R2R.
src/coreclr/jit/objectalloc.h	Added `OAT_NEWARR_R2R` enum value.
src/coreclr/jit/objectalloc.cpp	Treat `OAT_NEWARR_R2R` like `OAT_NEWARR` and dump a debug message.
src/coreclr/jit/inlinepolicy.h	Added `m_MayReturnSmallArray` field to `DefaultPolicy`.
src/coreclr/jit/inlinepolicy.cpp	Handle `CALLEE_MAY_RETURN_SMALL_ARRAY` in `NoteBool` and boost multiplier.
src/coreclr/jit/helperexpansion.cpp	Support `CORINFO_HELP_READYTORUN_NEWARR_1` in `fgExpandStackArrayAllocation`.

Copilot · 2025-06-13T20:18:24Z

src/coreclr/jit/helperexpansion.cpp

@@ -2829,6 +2829,10 @@ bool Compiler::fgExpandStackArrayAllocation(BasicBlock* block, Statement* stmt,
            typeArgIndex   = 0;
            break;

+        case CORINFO_HELP_READYTORUN_NEWARR_1:
+            lengthArgIndex = 0;


In the READYTORUN_NEWARR_1 case, typeArgIndex is never initialized, leading to undefined behavior when later checking its value; consider setting typeArgIndex = -1 explicitly.

Suggested change

lengthArgIndex = 0;

lengthArgIndex = 0;

typeArgIndex = -1;

It is initialized to -1 just above.

Copilot · 2025-06-13T20:18:24Z

src/coreclr/jit/objectalloc.cpp

+                if ((call->gtArgs.CountUserArgs() == 1) && call->gtArgs.GetUserArgByIndex(0)->GetNode()->IsCnsIntOrI())
+                {
+                    allocType = OAT_NEWARR_R2R;
+                    JITDUMP("Checking if we can stack allocate array [%06u])\n", comp->dspTreeID(call));


[nitpick] The debug log string has a mismatched parenthesis ([%06u])), which may confuse readers; consider correcting it to [%06u].

Suggested change

JITDUMP("Checking if we can stack allocate array [%06u])\n", comp->dspTreeID(call));

JITDUMP("Checking if we can stack allocate array [%06u]\n", comp->dspTreeID(call));

AndyAyersMS · 2025-06-13T20:21:19Z

fyi @dotnet/jit-contrib

Note the handle embedding call may fail and so cause R2R compilation of a method to be abandoned. We are probably better off not stack allocating in such cases since the method will end up being jitted at Tier0 and allocate anyways. But I don't think there is any way to tell if an embedding request will fail and if so avoid making it.

This doesn't quite fix all of #113236, as the TryWriteBytes methods are still not inlined. I currently don't see an obvious tweak we can make in the heuristics so we may need to decide if AggressiveInlining is appropriate.

(One might hope that "argument is a small locally allocated array" might be a reasonable inlining boost, but these arrays are span captured so not passed directly).

AndyAyersMS · 2025-06-14T01:14:30Z

Failures in readytorun/tests/mainv1/mainv1.cmd and similar are likely methods unexpectedly dropping out of R2R because of the embedding issue (still need to verify).

…licy

jkotas · 2025-06-17T17:56:39Z

src/coreclr/jit/objectalloc.cpp

@@ -1449,6 +1476,30 @@ bool ObjectAllocator::MorphAllocObjNodeHelperArr(AllocationCandidate& candidate)
        return false;
    }

+    // Under R2R, for array allocations that would require handle embedding, check if the embedding will succeed.


I do not see what's special about arrays that prevents the array type handle from getting embedded. This sounds like a bug in crossgen2 driver. Do you happen to know where the embedding fails? I am sorry I did not have a chance to take a look at this in detail.

I'll work up a simple repro and get add more details.

Simple repro (requires this PR)

class EmbedIssue { public static int Main() { int[] a = new int[10]; for (int i = 0; i < a.Length; i++) { a[i] = i; } int sum = 0; for (int i = 0; i < a.Length; i++) { sum += a[i]; } return sum; } }

The JIT proves new int[10] can't escape; invokes embedClassHandle on int32[], this isn't in the version checked cache, it is a parameterized type, so the next check is check for int32, this is in the cache and is set to false, so the whole embedding request fails. I don't know how int32 gets into the cache.

With the latest commit for this PR we try embedding early, catch the failure in the JIT, and continue compiling without stack allocating the array.

I'm curious, from where is embedClassHandle called normally that fails the compilation?

Importation of CEE_NEWARR takes care not to embed the handle. Instead, a call to a new array helper is generated by R2R that only embeds the element type. The array type shows up nowhere in the IL, so there is no token to represent it. I'm not sure that R2R has a fixup required to be able to embed the array class handle, so probably a new one would need to be added.

Edit: although I guess for int[] specifically it should always be possible to encode its signature...

The second call is in helper expansion. If we stack allocate the array we store the method table pointer.

Now it turns out currently that jitted code actually never looks at the method table pointer of a on stack array. But I have been saving it there because the debugger then displays the local properly, and someday we may add support in the runtime helpers for handling on-stack objects so we may see some non-jitted code accesses.

Hmm, I think I misunderstood that. The new array helper does embed the array type signature successfully, it seems. It doesn't embed the element type.

I'm not sure that R2R has a fixup required to be able to embed the array class handle,

R2R does have a fixup to embed type handles (READYTORUN_FIXUP_TypeHandle). It is used in other places.

Importation of CEE_NEWARR takes care not to embed the handle.

This was meant to be an optimization to make the code a bit smaller and to allow building the runtime type only once it is really needed. It is debatable whether this is optimization is worth it. Dynamically emitting the little helper is more expensive than what it used to be when this optimization was introduced b/c WriteXorExecute, and relatively expensive FlushInstructionCache needed on Arm64.

Yeah, I think I understand that better now. The NewArr fixup takes a signature of the array type and crossgen2 ought to be able to pass the exact same signature to the TypeHandle fixup instead.

AndyAyersMS · 2025-06-18T15:06:37Z

@dotnet/jit-contrib ping

jakobbotsch

LGTM, assuming we don't want to wait for the crossgen2 fix

jkotas · 2025-06-18T16:27:28Z

I would prefer to wait for the proper fix in crossgen2.

AndyAyersMS · 2025-06-18T17:26:53Z

I would prefer to wait for the proper fix in crossgen2.

Sounds good, then we can pare back the AggressiveOptimization in the test case to just the ones that require inlining.

If you give me some pointers on what to look at here for fixing crossgen2, I can give it a try.

jkotas · 2025-06-19T06:03:16Z

I think the VersionswWithType check in embedClassHandle is superfluous. Trying to delete in #116808

AndyAyersMS · 2025-07-08T18:36:04Z

Per @davidwrighton a fix is not likely before the preview 7 snap.

AndyAyersMS · 2025-07-15T00:46:50Z

Per @davidwrighton a fix is not likely before the preview 7 snap.

AndyAyersMS marked this pull request as ready for review June 13, 2025 20:16

Copilot AI review requested due to automatic review settings June 13, 2025 20:16

github-actions bot added the area-CodeGen-coreclr label Jun 13, 2025

dotnet-policy-service bot assigned AndyAyersMS Jun 13, 2025

Copilot AI reviewed Jun 13, 2025

View reviewed changes

add can embed check; exempt more tests from R2R because of the new po…

7834e46

…licy

jkotas reviewed Jun 17, 2025

View reviewed changes

jakobbotsch approved these changes Jun 18, 2025

View reviewed changes

jkotas mentioned this pull request Jun 19, 2025

Delete VersionsWithType check from embedClassHandle #116808

Open

AndyAyersMS mentioned this pull request Jul 9, 2025

Escape Analysis: Elide an array allocation in BitConverter.GetBytes pattern #113236

Open

5 tasks

AndyAyersMS closed this Jul 15, 2025

AndyAyersMS reopened this Jul 15, 2025

AndyAyersMS mentioned this pull request Jul 15, 2025

Crossgen outerloop regression: JIT/opt/ObjectStackAllocation/ObjectStackAllocationTests/ObjectStackAllocationTests.cmd #109314

Open

build-analysis bot mentioned this pull request Jul 15, 2025

The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008

Open

3 tasks

	JITDUMP("Checking if we can stack allocate array [%06u])\n", comp->dspTreeID(call));
	JITDUMP("Checking if we can stack allocate array [%06u]\n", comp->dspTreeID(call));

JIT: enable stack allocation of more arrays in R2R #116651

Are you sure you want to change the base?

JIT: enable stack allocation of more arrays in R2R #116651

Conversation

AndyAyersMS commented Jun 13, 2025

Uh oh!

dotnet-policy-service bot commented Jun 13, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Copilot AI Jun 13, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jun 13, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AndyAyersMS commented Jun 13, 2025

Uh oh!

AndyAyersMS commented Jun 14, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jakobbotsch Jun 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jakobbotsch Jun 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AndyAyersMS commented Jun 18, 2025

Uh oh!

jakobbotsch left a comment

Choose a reason for hiding this comment

Uh oh!

jkotas commented Jun 18, 2025

Uh oh!

AndyAyersMS commented Jun 18, 2025

Uh oh!

jkotas commented Jun 19, 2025

Uh oh!

AndyAyersMS commented Jul 8, 2025

Uh oh!

AndyAyersMS commented Jul 15, 2025

Uh oh!

Uh oh!

jakobbotsch Jun 18, 2025 •

edited

Loading

jakobbotsch Jun 18, 2025 •

edited

Loading