-
Notifications
You must be signed in to change notification settings - Fork 5.1k
JIT: revise escape analysis bit vector usage #113711
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: revise escape analysis bit vector usage #113711
Conversation
This change decouples the "bv" space (used for the connection graph and related data) from the "lclnum" space, so that the graph nodes can represent other entities that are not locals. Conditional escape analysis introduced pseudo-locals, so we already had this notion, but it was implicit, and extending it further (for say fields) was proving awkward. So now it is explicit. The one tricky aspect is that as the analysis proceeds we may introduce new locals that we want to track, so we need to anticipate this and leave bv space for them, since our bv length must be known in advance. Only a subset of locals need to be analyzed, so in some (many?) cases the overall BV lengths should decrease, though there is now a bit more work to interpret what the bits mean. We reuse the tracked var concept and data structures for locals, eg to map from bv index to local num; for other entities the mappings are one-to-one so reverse mapping doesn't require table lookups.
@dotnet/jit-contrib would appreciate suggestions here on how to make this more robust. My main concern is that it is still too easy to get confused between indices and lcl var nums. I am thinking I should try and encapsulate this more strongly, eg a struct with tag/value for the different entity types or something. Any ideas? I'd like to do this revision before finishing up the field-wise cases, as those will introduce new node types that don't correspond directly to locals. This revision should be no diff. |
There is a TP hit in minopts... looks like I should defer all the BV computation until |
Diffs don't make sense on first glance, LSRA decides to split a critical edge in base but not in diff, but there are no visible diffs in the dump before this point. |
I think we may need to introduce a node for each field of the local if we want to do field-wise analysis, so that the |
Yes, that is the kind of thing this change enables. Though likely we'll just use one pseudo-field per type, representing all the GC typed fields of the type. |
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.
Copilot reviewed 1 out of 2 changed files in this pull request and generated no comments.
Files not reviewed (1)
- src/coreclr/jit/objectalloc.h: Language not supported
@dotnet/jit-contrib PTAL No diffs in latest run. |
// showing how locals can assign values to one another. | ||
// | ||
// The graph also includes a few absract node types: a node representing | ||
// an unknow source of values, and (pseudo local) nodes representing |
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: typo
// an unknow source of values, and (pseudo local) nodes representing | |
// an unknown source of values, and (pseudo local) nodes representing |
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.
I'll fix this when I actually add the "unknow" source... also similar typo just above "absract".
This change decouples the "bv" space (used for the connection graph and related data) from the "lclnum" space, so that the graph nodes can represent other entities that are not locals.
Conditional escape analysis introduced pseudo-locals, so we already had this notion, but it was implicit, and extending it further (for say fields) was proving awkward. So now it is explicit.
The one tricky aspect is that as the analysis proceeds we may introduce new locals that we want to track, so we need to anticipate this and leave bv space for them, since our bv length must be known in advance.
Only a subset of locals need to be analyzed, so in some (many?) cases the overall BV lengths should decrease, though there is now a bit more work to interpret what the bits mean.
We reuse the tracked var concept and data structures for locals, eg to map from bv index to local num; for other entities the mappings are one-to-one so reverse mapping doesn't require table lookups.