Skip to content

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

Merged
merged 1 commit into from
Jul 31, 2020
Merged

Conversation

erozenfeld
Copy link
Member

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.

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.
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jul 30, 2020
@erozenfeld
Copy link
Member Author

@AndyAyersMS @dotnet/jit-contrib PTAL

@erozenfeld erozenfeld requested a review from AndyAyersMS July 30, 2020 22:28
Copy link
Member

@AndyAyersMS AndyAyersMS left a 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;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const isn't sufficient...?

Copy link
Member Author

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.

@erozenfeld
Copy link
Member Author

CopyCtorTest fails in other PRs as well, e.g., #40160.
@davidwrighton

@davidwrighton
Copy link
Member

@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.

@erozenfeld erozenfeld merged commit 0f36487 into dotnet:master Jul 31, 2020
Jacksondr5 pushed a commit to Jacksondr5/runtime that referenced this pull request Aug 10, 2020
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.
@karelz karelz added this to the 5.0.0 milestone Aug 18, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Perf -10%] System.Text.RegularExpressions.Tests.Perf_Regex_Common (2)
5 participants