-
Notifications
You must be signed in to change notification settings - Fork 5k
Re-work fix for flow graph update. #40162
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
Conversation
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.
@AndyAyersMS @dotnet/jit-contrib PTAL |
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.
LGTM
@@ -3722,7 +3726,8 @@ PhaseStatus Compiler::fgInsertGCPolls() | |||
{ | |||
noway_assert(opts.OptimizationEnabled()); | |||
fgReorderBlocks(); | |||
fgUpdateChangedFlowGraph(); | |||
constexpr bool computeDoms = false; |
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.
const
isn't sufficient...?
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.
const
would've worked too.
CopyCtorTest fails in other PRs as well, e.g., #40160. |
@erozenfeld Yes I've noticed that. I've just disabled the test on Mono, and have a PR out to fix it on X86. Sorry about that. |
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 resultedin 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% regressionbecause 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.