-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Fix fgUpdateChangedFlowGraph
.
#39878
Conversation
`fgComputeDoms` has an assumption that the flow graph has no unreachable blocks. It's checked with this assert: https://github.com/dotnet/runtime/blob/ad325b014124b1adb9306abf95fdac85e3f7f2f4/src/coreclr/src/jit/flowgraph.cpp#L2342 This assert fired when testing dotnet#39474 (`Convert Math{F}.CoreCLR methods from FCall to QCall`) when we are updating the flow graph after inserting GC polls. This change switches `fgUpdateChangedFlowGraph` to call `fgComputeReachability`, which both removes unreachable blocks and calls `fgComputeDoms`. pin-icount reported a 0.0043% throughput improvement, which is within noise level.
x64 framework pmi diffs:
|
In addition to removing unreachable blocks |
@AndyAyersMS @dotnet/jit-contrib PTAL |
|
|
In dotnet#39878 I switched fgUpdateChangedFlowGraph to call fgComputeReachability, which both removes unreachable blocks and calls fgComputeDoms. As mentioned in that PR, in addition to removing unreachable blocks fgRemoveUnreachableBlocks updates `BBF_LOOP_HEAD` flags even if no unreachable blocks were found. That resulted in some diffs, both positive and negative, from downstream effects: e.g., in some cases we now recognize more loops, which changes weights, etc. Some of the negative diffs affected benchmarks we are tracking, e.g., in dotnet#40094 `System.Text.RegularExpressions.Tests.Perf_Regex_Common` had a 10% regression because of codegen diffs in the large dynamic method created when compiling regular expressions. Because of these regressions, I decided to go with a more surgical fix for the original issue (assert when computing dominators after inlining GC polls). The downstream phases don't really need the dominator info so I changed fgUpdateChangedFlowGraph to not re-compute dominators after GC poll inlining. This reverses all diffs from dotnet#39878 and fixes dotnet#40094.
In #39878 I switched fgUpdateChangedFlowGraph to call fgComputeReachability, which both removes unreachable blocks and calls fgComputeDoms. As mentioned in that PR, in addition to removing unreachable blocks fgRemoveUnreachableBlocks updates `BBF_LOOP_HEAD` flags even if no unreachable blocks were found. That resulted in some diffs, both positive and negative, from downstream effects: e.g., in some cases we now recognize more loops, which changes weights, etc. Some of the negative diffs affected benchmarks we are tracking, e.g., in #40094 `System.Text.RegularExpressions.Tests.Perf_Regex_Common` had a 10% regression because of codegen diffs in the large dynamic method created when compiling regular expressions. Because of these regressions, I decided to go with a more surgical fix for the original issue (assert when computing dominators after inlining GC polls). The downstream phases don't really need the dominator info so I changed fgUpdateChangedFlowGraph to not re-compute dominators after GC poll inlining. This reverses all diffs from #39878 and fixes #40094.
`fgComputeDoms` has an assumption that the flow graph has no unreachable blocks. It's checked with this assert: https://github.com/dotnet/runtime/blob/ad325b014124b1adb9306abf95fdac85e3f7f2f4/src/coreclr/src/jit/flowgraph.cpp#L2342 This assert fired when testing dotnet#39474 (`Convert Math{F}.CoreCLR methods from FCall to QCall`) when we are updating the flow graph after inserting GC polls. This change switches `fgUpdateChangedFlowGraph` to call `fgComputeReachability`, which both removes unreachable blocks and calls `fgComputeDoms`. pin-icount reported a 0.0043% throughput improvement, which is within noise level.
In dotnet#39878 I switched fgUpdateChangedFlowGraph to call fgComputeReachability, which both removes unreachable blocks and calls fgComputeDoms. As mentioned in that PR, in addition to removing unreachable blocks fgRemoveUnreachableBlocks updates `BBF_LOOP_HEAD` flags even if no unreachable blocks were found. That resulted in some diffs, both positive and negative, from downstream effects: e.g., in some cases we now recognize more loops, which changes weights, etc. Some of the negative diffs affected benchmarks we are tracking, e.g., in dotnet#40094 `System.Text.RegularExpressions.Tests.Perf_Regex_Common` had a 10% regression because of codegen diffs in the large dynamic method created when compiling regular expressions. Because of these regressions, I decided to go with a more surgical fix for the original issue (assert when computing dominators after inlining GC polls). The downstream phases don't really need the dominator info so I changed fgUpdateChangedFlowGraph to not re-compute dominators after GC poll inlining. This reverses all diffs from dotnet#39878 and fixes dotnet#40094.
fgComputeDoms
has an assumption that the flow graphhas no unreachable blocks. It's checked with this assert:
runtime/src/coreclr/src/jit/flowgraph.cpp
Line 2342 in ad325b0
This assert fired when testing #39474 (
Convert Math{F}.CoreCLR methods from FCall to QCall
)when we are updating the flow graph after inserting GC polls.
This change switches
fgUpdateChangedFlowGraph
to callfgComputeReachability
,which both removes unreachable blocks and calls
fgComputeDoms
.pin-icount reported a 0.0043% throughput improvement, which is within noise level.