JIT: fix CEA to handle a few more cases #122946
Conversation
Conditional escape analysis was not happening when an object's `GetEnumerator` returns the result of another `GetEnumerator` call. These calls must be specially flagged and the JIT was not handling this case. Fix the flagging logic so that when processing a return from a flagged inlinee, if the return value is a call, also flag that call. Also relax a constraint on the location of enumerator temp appearances, as there can now be another layer of temp assignments involved in returning the enumerator instance. Closes dotnet#122856.
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
There was a problem hiding this comment.
Pull request overview
This PR enhances conditional escape analysis (CEA) in the JIT compiler to properly handle scenarios where a GetEnumerator method returns the result of another GetEnumerator call. The fix ensures that enumerator allocation tracking propagates correctly through nested GetEnumerator calls and adjusts domination constraints for the empty static pattern.
Key changes:
- Added logic to transfer enumerator GDV flags from an inlined call to its returned call when the return value is also a call
- Relaxed domination constraints for empty static cases to allow temp appearances dominated by the allocation block's unique predecessor
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/coreclr/jit/importer.cpp | Added logic in return instruction handling to propagate enumerator GDV flags to nested GetEnumerator calls during inlining |
| src/coreclr/jit/objectalloc.cpp | Modified domination checking to allow temp appearances to be dominated by the allocation block's unique predecessor in empty static patterns |
The changes look reasonable and follow established patterns in the codebase. The logic is clear and well-commented. The implementation correctly handles the case where GetEnumerator is implemented by calling another GetEnumerator method, which was preventing conditional escape analysis from working properly.
|
@dotnet/jit-contrib PTAL Recall the flagging logic identifies a particular enumerable ALLOCOBJ that is inside of a GDV diamond with the variable that will ultimately be assigned the result of the entire GDV... that variable (or copies thereof) is then type tested in downstream GDVs during enumeration. This flagging triggers the conditional escape logic for accesses guarded by the downstream GDVs. The flag starts out mapping the initial interface call site, eg and then is moved to the exact call when the GDV expands: and then is moved to the allocobj once this is devirtualized and inlined. In the cases up until now the inline of that first Now the JIT can handle cases where that first inline exposes a second (or further nested) Note if for some reason there were multiple Two diffs in SPMI where we do more stack allocation, plus 20 or so context misses likely indicating more diffs if we had proper context information. |
|
/ba-g IOS dead letter |
Conditional escape analysis was not happening when an object's
GetEnumeratorreturns the result of anotherGetEnumeratorcall. These calls must be specially flagged and the JIT was not handling this case.Fix the flagging logic so that when processing a return from a flagged inlinee, if the return value is a call, also flag that call.
Also relax a constraint on the location of enumerator temp appearances, as there can now be another layer of temp assignments involved in returning the enumerator instance.
Closes #122856.