Skip to content

Conversation

@AndyAyersMS
Copy link
Member

Conditional Escape Analysis (CEA) is currently driven by flagging GDV calls made to IEnumerable<T>.GetEnumerator. Generalize this slightly to instead look for any call that returns an IEnumerator<T>, since there are some classes that return enumerators via other calls. These calls likely won't be GDVs; I will address adapting CEA to handle that in subsequent changes.

…umerator<T>`

Conditional Escape Analysis (CEA) is currently driven by flagging GDV calls
made to `IEnumerable<T>.GetEnumerator`. Generalize this slightly to instead look
for any call that returns an `IEnumerator<T>`, since there are some classes that
return enumerators via other calls. These calls likely won't be GDVs; I will address
adapting CEA to handle that in subsequent changes.
Copilot AI review requested due to automatic review settings June 24, 2025 18:38
@github-actions github-actions bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Jun 24, 2025
@AndyAyersMS
Copy link
Member Author

AndyAyersMS commented Jun 24, 2025

SPMI not going to be helpful here, but I should be able to replay a bespoke collection on this PR vs base. Expecting no diffs (or at least no lost CEAs).

Also this PR still includes the "old way" of checking for flagged calls, and an assert if the old way ever finds one that the new way doesn't.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR broadens escape analysis to flag any calls returning IEnumerator<T> rather than only IEnumerable<T>.GetEnumerator.

  • Updated IntrinsicAttribute to apply to interfaces.
  • Marked IEnumerator<T> as intrinsic in CoreLib.
  • Enhanced JIT importer to detect calls whose return type is IEnumerator<T> via metadata inspection.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File Description
src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/IntrinsicAttribute.cs Allow [Intrinsic] on interfaces
src/coreclr/nativeaot/Runtime.Base/src/System/Runtime/CompilerServices/IntrinsicAttribute.cs Same interface support in NativeAOT runtime
src/libraries/System.Private.CoreLib/src/System/Collections/Generic/IEnumerator.cs Added [Intrinsic] to generic IEnumerator
src/coreclr/jit/importer.cpp Generalized detection logic to “returning IEnumerator”
Comments suppressed due to low confidence (2)

src/coreclr/jit/importer.cpp:6975

  • The new isEnumeratorT path handles non-GDV calls returning IEnumerator<T>, but there are no tests covering this scenario. Consider adding a JIT import or codegen test that invokes a custom method returning IEnumerator<T> to verify escape analysis is applied correctly.
                        if (isEnumeratorT)

src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/IntrinsicAttribute.cs:9

  • The summary comment above this attribute should be updated to mention that interfaces are now supported as intrinsic targets, improving clarity for future maintainers.
    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct | AttributeTargets.Method | AttributeTargets.Constructor | AttributeTargets.Field | AttributeTargets.Interface, Inherited = false)]

Comment on lines +6949 to +6951
if ((strcmp(namespaceName, "System.Collections.Generic") == 0) &&
(strcmp(className, "IEnumerator`1") == 0))
{
Copy link

Copilot AI Jun 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nitpick] Comparing namespace and class names with strcmp on every call can be inefficient. Consider caching the CORINFO_CLASS_HANDLE for IEnumerator and directly comparing handles to avoid repeated string comparisons.

Suggested change
if ((strcmp(namespaceName, "System.Collections.Generic") == 0) &&
(strcmp(className, "IEnumerator`1") == 0))
{
static CORINFO_CLASS_HANDLE cachedIEnumeratorHandle = NO_CLASS_HANDLE;
if (cachedIEnumeratorHandle == NO_CLASS_HANDLE)
{
cachedIEnumeratorHandle = info.compCompHnd->findClass("System.Collections.Generic", "IEnumerator`1");
}
if (retCls == cachedIEnumeratorHandle)
{

Copilot uses AI. Check for mistakes.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, copilot. There is no findClass like this.

@AndyAyersMS AndyAyersMS added area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Jun 24, 2025
@AndyAyersMS
Copy link
Member Author

SPMI not going to be helpful here, but I should be able to replay a bespoke collection on this PR vs base. Expecting no diffs (or at least no lost CEAs).

No diffs in a bespoke SPMI... going to do some other spot checks and also have an issue in NAOT to chase down.

@AndyAyersMS
Copy link
Member Author

SPMI not going to be helpful here, but I should be able to replay a bespoke collection on this PR vs base. Expecting no diffs (or at least no lost CEAs).

No diffs in a bespoke SPMI... going to do some other spot checks and also have an issue in NAOT to chase down.

Ah, NAOT is using its exact devirt rules, so the return type is often an instantiated IEnumerator. Will just remove the check since it's served its purpose.

@AndyAyersMS
Copy link
Member Author

@dotnet/jit-contrib PTAL

No diffs though hard to see this from CI. Failures are unrelated.

const char* className = info.compCompHnd->getClassNameFromMetadata(retCls, &namespaceName);

if ((strcmp(namespaceName, "System.Collections.Generic") == 0) &&
(strcmp(className, "IEnumerator`1") == 0))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps move this check in lookupNamedIntrinsic and rename NI_System_Collections_Generic_IEnumerable_GetEnumerator since the constant is now unsued.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lookupNamedIntrinsic is for methods. This is a class check.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the now unneded constant and lookup support.

const char* className = info.compCompHnd->getClassNameFromMetadata(retCls, &namespaceName);

if ((strcmp(namespaceName, "System.Collections.Generic") == 0) &&
(strcmp(className, "IEnumerator`1") == 0))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I'd expect the className comparison to fail faster than the namespaceName comparison -- should we swap the order?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. Might be small compared the cost of obtaining the strings in the first place, but every cycle counts.

Will do this in a subsequent PR.

@github-actions github-actions bot locked and limited conversation to collaborators Jul 26, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants