-
Notifications
You must be signed in to change notification settings - Fork 5.1k
JIT: switch escape analysis flagging to look for calls returning IEnumerator<T>
#116978
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JIT: switch escape analysis flagging to look for calls returning IEnumerator<T>
#116978
Conversation
…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.
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. |
There was a problem hiding this 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 returningIEnumerator<T>
, but there are no tests covering this scenario. Consider adding a JIT import or codegen test that invokes a custom method returningIEnumerator<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)]
if ((strcmp(namespaceName, "System.Collections.Generic") == 0) && | ||
(strcmp(className, "IEnumerator`1") == 0)) | ||
{ |
There was a problem hiding this comment.
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.
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.
There was a problem hiding this comment.
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.
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. |
@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)) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
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 anIEnumerator<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.