JIT: Add helper method for updating bbTargetEdge

[amanasifkhalid]

Part of #93020. Adds fgRedirectTargetEdge, which updates bbTargetEdge's block target while maintaining the rest of the edge's state to simplify edge profile maintenance (and avoid additional allocations). My goal is to eventually have some generalized version of this that can replace any block's successor edges without having to consider the block's kind, such as by updating the edge via a FlowEdge**. I tried this locally, and there are some quirks around duplicate edges that complicate this approach, and it might make sense to have a fast path for updating blocks with only one successor anyway, so I'm starting here.

Note that I didn't update fgReplaceJumpTarget to use this yet, as the method is frequently called while iterating a block's predecessors, and fgRedirectTargetEdge modifies bbPreds, breaking the iterator. This can be easily fixed through multiple approaches, though I'm not sure which one is preferable:

• We could convert problematic iterator usages to raw loops that cache the next pred edge pointer before calling fgReplaceJumpTarget, though this isn't as elegant.
• We already have a m_next pointer in pred iterators in Debug builds for consistency checking. We can make this available all the time, and then update the iterator to it instead of using m_pred->getNextPredEdge, as that will traverse the pred list of the new target. This will impact TP, so perhaps this should be tried in a separate PR.
• To lessen the TP impact of the above approach, we could add a new iterator type that caches the next pred edge specifically for these situations, though it might be confusing having multiple pred iterator types.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Part of #93020. Adds fgRedirectTargetEdge, which updates bbTargetEdge's block target while maintaining the rest of the edge's state to simplify edge profile maintenance (and avoid additional allocations). My goal is to eventually have some generalized version of this that can replace any block's successor edges without having to consider the block's kind, such as by updating the edge via a FlowEdge**. I tried this locally, and there are some quirks around duplicate edges that complicate this approach, and it might make sense to have a fast path for updating blocks with only one successor anyway, so I'm starting here.

Note that I didn't update fgReplaceJumpTarget to use this yet, as the method is frequently called while iterating a block's predecessors, and fgRedirectTargetEdge modifies bbPreds, breaking the iterator. This can be easily fixed through multiple approaches, though I'm not sure which one is preferable:

• We could convert problematic iterator usages to raw loops that cache the next pred edge pointer before calling fgReplaceJumpTarget, though this isn't as elegant.
• We already have a m_next pointer in pred iterators in Debug builds for consistency checking. We can make this available all the time, and then update the iterator to it instead of using m_pred->getNextPredEdge, as that will traverse the pred list of the new target. This will impact TP, so perhaps this should be tried in a separate PR.
• To lessen the TP impact of the above approach, we could add a new iterator type that caches the next pred edge specifically for these situations, though it might be confusing having multiple pred iterator types.

Author:	amanasifkhalid
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[amanasifkhalid]

cc @dotnet/jit-contrib, @AndyAyersMS PTAL. This change has some small diffs. I was expecting this to be a no-diff change, but it looks like there are a few fgAddRefPred call sites where we previously didn't carry over the old edge's weight, so we would calculate the min/max weights using block weights; now that we just keep the old edge, the existing edge weights are automatically preserved. This seems to influence fgReorderBlocks in a few methods.

[AndyAyersMS]

• To lessen the TP impact of the above approach, we could add a new iterator type that caches the next pred edge specifically for these situations, though it might be confusing having multiple pred iterator types.

We had this sort of setup in Phoenix, there were "Editing" iterators that allowed modification with explicit resume points, and regular iterators that did a limited amount of checking in debug to try and verify the collections weren't modified.

[AndyAyersMS]

Just one comment typo -- feel free to fix later.

[amanasifkhalid]

We had this sort of setup in Phoenix, there were "Editing" iterators that allowed modification with explicit resume points, and regular iterators that did a limited amount of checking in debug to try and verify the collections weren't modified.

I'm leaning towards this approach; I'll try this out in a follow-up PR.