-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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: Add pred block iterator that tolerates pred list modifications #99466
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
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 like this direction, but would prefer that the nature of the iterator be obvious from its name..
Maybe something like:
class PredBlockList
{
public:
static PredBlockList PredBlocks() const
{
return PredBlockList(bbPreds, /*allowEdits*/ false);
}
static PredBlockList PredBlocksEditing() const
{
return PredBlockList(bbPreds, /*allowEdits*/ true);
}
private:
PredBlockList(FlowEdge* list, bool allowEdits) {...};
};
src/coreclr/jit/block.h
Outdated
// If allowEdits=true, the user can modify the predecessor list while traversing it, | ||
// so (next == m_next) may not be true. Since we cached the next pointer in m_next, this won't break iteration. | ||
assert((next == m_next) || allowEdits); | ||
updateNextPointer = true; |
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.
This seems to be modifying live state under debug, which I think we should avoid.
@AndyAyersMS I separated out the |
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.
This looks great.
Thanks for the reviews! I should note that this change has small diffs from slight changes in edge weights. |
Follow-up to #99362.
fgRedirectTargetEdge
modifies the predecessor lists of the old and new successor blocks, so if we want to be able to use it infgReplaceJumpTarget
, we need a pred block iterator that is resilient to these changes, as we frequently call the latter method while iterating predecessors.I haven't found the need to update the pred edge iterator to allow updates too, but I imagine it would look the same as the pred block iterator.
fgTailMergeThrows
looks a bit awkward right now. After this change is merged, I plan to add a new method similar tofgRedirectTargetEdge
forBBJ_COND
blocks, and leverage it infgReplaceJumpTarget
. Since that new method will preserve edge weights, we won't lose anything infgTailMergeThrows
by just callingfgReplaceJumpTarget
. I think that will be a good opportunity to clean upfgTailMergeThrows
by getting rid of all its helpers for updating edges.cc @dotnet/jit-contrib, @AndyAyersMS PTAL.