-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Merge return true/false blocks #94387
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsCI experiment, some nice diffs locally
|
d4c1115
to
7228009
Compare
2ccbd30
to
9b96fd0
Compare
@AndyAyersMS @jakobbotsch @dotnet/jit-contrib PTAL, the current shape is what @jakobbotsch suggested in #94387 (comment) (basically, his branch), my initial one was focusing on I've limitted it to single-statement RETURN blocks, but it seems like it makes sense to enable it for all, but that will require some careful analysis of TP/Size regressions (up to +0.4% TP impact) + needs a small fix in morph for explicit tail calls (I or Jakob will try to land it separately).
but overall it's a clear size win: https://dev.azure.com/dnceng-public/public/_build/results?buildId=463538&view=results I also expect to see some improvements when I expand |
src/coreclr/jit/block.cpp
Outdated
} | ||
|
||
const Statement* stmt = firstStmt(); | ||
while (ignoreNopStatements && ((stmt->GetRootNode() == nullptr) || (stmt->GetRootNode()->OperIs(GT_NOP)))) |
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.
Is a statement with a null node possible? Overall, do we actually find any NOPs in the return blocks?
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 wasn't sure in this, but if I remove the nullcheck it won't fail on CI so I presume it's not possible? I wish we could have a centralized "IR reference" where we could check what's legal and what's not in IR
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.
Is a statement with a null node possible? Overall, do we actually find any NOPs in the return blocks?
I'll check the diffs
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.
It is not possible.
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.
Reverted these changes, there were no additional diffs from that
predInfo.Emplace(predBlock, lastStmt); | ||
} | ||
|
||
auto tailMergePreds = [&](BasicBlock* commSucc) -> bool { |
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.
It would be nice to convert these to functions instead of massive lambdas... but that's a no-diff refactoring to be done separately.
src/coreclr/jit/gentree.cpp
Outdated
@@ -2519,6 +2519,12 @@ bool GenTreeCall::Equals(GenTreeCall* c1, GenTreeCall* c2) | |||
return false; | |||
} | |||
|
|||
// Make sure "explicit tail call" flags match. | |||
if (c1->IsTailPrefixedCall() != c2->IsTailPrefixedCall()) |
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 think this should be reverted (and fixed in the future PR), or we should check all the tailcall flags.
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.
Reverted
I'm surprised checkin more statements has such a TP impact; it should be fairly self-limiting as there can't be that many return blocks. Unless it's enabling a lot more merging? |
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 don't have anything to add other that what's already been noted.
Cool that this was relatively refactoring simple; I recall working on this a while back but got bogged down for some reason.
c2b440f
to
cfcd2a5
Compare
it's possible that the TP regressions in that case come from extra loop clonning etc, I'll check separately, this PR will help to isolate those changes |
I plan to unconditionally expand all
return <condition>
blocks toJTRUE
, merge tails (this PR) and then fold toreturn <condition>;
back if tails were not found.Diffs