JIT: enhance escape analysis to understand local struct fields #113977
Conversation
Continuation of dotnet#113141 Implement a very simplistic "field sensitive" analysis for gc structs where we model each struct as simply its gc field(s). That is, given a gc struct `G` with GC field `f`, we model ``` G.f = ... ``` as an assignment to `G` and ``` = G.f ``` as a read from `G`. Since we know `G` itself cannot escape, "escaping" of `G` means `G.f` can escape. Note this conflates the fields of `G`: either they all escape or none of them do. We could make this more granular but it's not clear that doing so is worthwhile, and it requires more up-front work to determine how to track each field's status. If the struct or struct fields are only consumed locally, we may be able to prove the gc referents don't escape. This is a subset/elaboration of dotnet#112543 that does not try and reason interprocedurally. Contributes to dotnet#104936 / dotnet#108913 Fixes dotnet#113236 (once the right inlines happen)
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
There was a problem hiding this comment.
Pull Request Overview
This pull request enhances the JIT escape analysis by introducing field‐sensitive handling of GC structs and expanding test coverage for various scenarios involving spans and struct escapes. Key changes include the addition of new GC struct definitions and related tests, multiple span capture/escape test methods, and adjustments to the allocation verification logic in the tests.
Files not reviewed (6)
- src/coreclr/jit/compiler.h: Language not supported
- src/coreclr/jit/jitconfigvalues.h: Language not supported
- src/coreclr/jit/layout.cpp: Language not supported
- src/coreclr/jit/layout.h: Language not supported
- src/coreclr/jit/objectalloc.cpp: Language not supported
- src/coreclr/jit/objectalloc.h: Language not supported
Comments suppressed due to low confidence (2)
src/tests/JIT/opt/ObjectStackAllocation/ObjectStackAllocationTests.cs:476
- The method 'SpanCaptureArray3' is defined but never invoked by any test. Consider adding a test call (via CallTestAndVerifyAllocation) or removing the method if it is not needed.
static int SpanCaptureArray3()
src/tests/JIT/opt/ObjectStackAllocation/ObjectStackAllocationTests.cs:512
- The 'SpanEscapeArrayReturn' method is defined but not used in any test invocation. Consider adding a corresponding test or removing the method if it is unnecessary.
static int SpanEscapeArrayReturn() => SpanEscapeArrayReturnHelper()[10];
| g.a[0] = "Goodbye"; | ||
| g.b[0] = "Hello"; | ||
|
|
||
| ref string[] rs = ref g.b; |
There was a problem hiding this comment.
The use of a ref assignment between g.b and later g.a in a conditional block could benefit from a clarifying comment to explain the intended behavior.
Copilot is powered by AI, so mistakes are possible. Review output carefully before use.
|
@dotnet/jit-contrib PTAL This refreshes #113141 based on recent BV refactoring and other changes. I have not incorporated all the feedback from that PR yet, so feel free to re-raise. SPMI should do a decent job here demonstrating impact. I also haven't yet looked through all the regressions in detail. |
| { | ||
| gcType = TYPE_GC_BYREF; | ||
| } | ||
| SetGCPtr(startSlot + slot, gcType); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Same comment as previously.. This feels awfully specific to escape analysis to add in the generic builder type.
|
Current diffs. Looks like there is a bug to sort out first. |
Continuation of #113141
Implement a very simplistic "field sensitive" analysis for gc structs where we model each struct as simply its gc field(s).
That is, given a gc struct
Gwith GC fieldf, we modelas an assignment to
Gandas a read from
G. Since we knowGitself cannot escape, "escaping" ofGmeansG.fcan escape.Note this conflates the fields of
G: either they all escape or none of them do. We could make this more granular but it's not clear that doing so is worthwhile, and it requires more up-front work to determine how to track each field's status.If the struct or struct fields are only consumed locally, we may be able to prove the gc referents don't escape.
This is a subset/elaboration of #112543 that does not try and reason interprocedurally.
Contributes to #104936 / #108913
Fixes #113236 (once the right inlines happen)