-
Notifications
You must be signed in to change notification settings - Fork 5.2k
JIT: relax constraint in conditional escape analysis #117222
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
Conversation
Enable conditional escape analysis if the allocation was at one time guarded by a GDV, even if that GDV gets resolved by the new GDV cleanup pass that runs before escape analysis. Fixes dotnet#117204.
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 relaxes the constraint for conditional escape analysis by tracking allocations that were once guarded by a GDV even after the guard has been cleaned up.
- Removed the
m_domBlock
member and its assignments fromCloneInfo
- Eliminated the
IsGuarded
check so allGT_ALLOCOBJ
allocations are now unconditionally tracked - Cleaned up related debug dumps and comments
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
File | Description |
---|---|
src/coreclr/jit/objectalloc.h | Removed m_domBlock field from CloneInfo |
src/coreclr/jit/objectalloc.cpp | Removed guard check (IsGuarded ), always track allocations, and cleaned up info->m_domBlock assignment and debug dump |
Comments suppressed due to low confidence (3)
src/coreclr/jit/objectalloc.cpp:3320
- [nitpick] The comment still references GDV but the logic now tracks all allocations unconditionally. Consider updating it to reflect that allocations are always tracked regardless of any guard.
// This may be an allocation of a concrete class under GDV.
src/coreclr/jit/objectalloc.cpp:3317
- The change relaxes escape analysis constraints but introduces new behavior paths. Please add or update unit tests to cover allocations that were previously skipped when the guard was removed.
//
src/coreclr/jit/objectalloc.cpp:3320
- [nitpick] By removing the guard check, every
GT_ALLOCOBJ
goes through the cloning logic, which could increase compile-time work. Consider benchmarking or adding heuristics to avoid unintended performance regressions.
// This may be an allocation of a concrete class under GDV.
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
PTAL @dotnet/jit-contrib Because of the way Enumerator ALLOCOBJ flagging works we don't need to verify the allocation is currently guarded by a GDV; it only gets flagged when (in earlier phases) it was guarded. |
Proceed with CEA cloning even when the allocation site dominates the assignment to the enumerator var. The cloning will be a bit wasteful as the original code will become unreachable, but the code is set up to specialize the clone and so this is the less risky fix. Also restore recognition of `IEnumerable<T>.GetEnumerator` as this gives a useful inlining boost in some cases. Fixes dotnet#117204 cases that were not fixed by dotnet#117222.
Proceed with CEA cloning even when the allocation site dominates the assignment to the enumerator var. The cloning will be a bit wasteful as the original code will become unreachable, but the code is set up to specialize the clone and so this is the less risky fix. Also restore recognition of `IEnumerable<T>.GetEnumerator` as this gives a useful inlining boost in some cases. Fixes #117204 cases that were not fixed by #117222.
Enable conditional escape analysis if the allocation was at one time guarded by a GDV, even if that GDV gets resolved by the new GDV cleanup pass that runs before escape analysis.
Fixes #117204.