-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Expand BBJ_RETURN blocks with bool conditions #27167
Conversation
cc @dotnet/jit-contrib |
I wonder if the expansion part of this should be moved into the "constant value return merging" logic that was introduced in #13792. |
@AndyAyersMS will try! |
src/jit/optimizer.cpp
Outdated
{ | ||
continue; | ||
} | ||
|
||
if (!jumpBbReturnValue) | ||
{ | ||
// if jump target bb is `return false` we need to inverse comparison for our future `return expr` | ||
if (!returnOp->gtGetOp1()->OperIs(GT_EQ, GT_NE, GT_GT, GT_GE, GT_LT, GT_LE, GT_TEST_EQ, GT_TEST_NE)) | ||
if (!returnOp->gtGetOp1()->OperIs(GT_EQ, GT_NE)) |
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.
Why do you use
OperIs(GT_EQ, GT_NE, GT_GT, GT_GE, GT_LT, GT_LE, GT_TEST_EQ, GT_TEST_NE)
above on line 8975 and now use
OperIs(GT_EQ, GT_NE)
here?
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.
@briansull for some reason the extended list here regresses the diffs (I didn't investigate why yet) but yeah fgExpandBoolReturns
needs more work (probably it needs to access cost information to expand only simple ones)
a8fcbb5
to
6fb8a7c
Compare
Thank you for your contribution. As announced in dotnet/coreclr#27549 this repository will be moving to dotnet/runtime on November 13. If you would like to continue working on this PR after this date, the easiest way to move the change to dotnet/runtime is:
|
Thank you for your contribution. As announced in #27549 the dotnet/runtime repository will be used going forward for changes to this code base. Closing this PR as no more changes will be accepted into master for this repository. If you’d like to continue working on this change please move it to dotnet/runtime. |
Expand
BBJ_RETURN
basic blocks with boolean conditions, let me explain it via a pic:So it basically de-optimizes the control flow (optimized by Roslyn) but makes it a bit more friendly for optimizations, e.g. now both
BB1
andBB2
jump into the same block and can be now handled by the optOptimizeBools optimizations, e.g.:Was:
Now (without
optMergeBoolReturns
):With
optMergeBoolReturns
:So my de-optimization basically helped
optOptimizeBools
and now it's easier to go further and replace it with justreturn x | y != 0
without jumps (see https://github.com/dotnet/coreclr/issues/27148).The
fgExpandBoolReturns
andoptMergeBoolReturns
impl are just proof of concept so let me know please if I am moving in a wrong direction 🙂Jit diff:
Full diff: https://gist.github.com/EgorBo/6f84535bffe833981e550209dc1b8c56