-
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
JIT further Boolean logic optimization #55605
Comments
@JulieLeeMSFT I can have a look at it. Can you please direct me to any documentation for repreading ? |
Thanks @mano-si. I will assign this to you. I recommend reading from Attached jitdump output file
|
cc @TIHan |
Closing this issue as a lot of the cases have been resolved already. Below are the details.
[MethodImpl(MethodImplOptions.AggressiveInlining)]
private static bool IsEitherNegative(int a, int b)
{
return a < 0 || b < 0;
} JIT output:
Those three cases are simply not safe to do if
It's already optimized:
public static void TestBoolAsg(int a, int b, int c, ref bool z)
{
z = a == 0 && b == 0 && c == 0;
} When comparing the JIT output to this: public static bool TestBoolReturn(int a, int b, int c)
{
return a == 0 && b == 0 && c == 0;
}
vs.
Will make an issue regarding this specific case.
Because the current boolean optimizations are not extremely impactful, I think we could spend more time on other areas as messing with the cost values are not trivial to get right. |
This issue is to capture remaining work for #13573.
#49548 handled '==0' Boolean expression with two operands:
Current codegen:
Possible optimal codegen below, using the fact that the
or
instruction sets SF:Handle cases like bool b = a == 0 && b == 0 && c == 0 because the last block is a GT_ASG instead of GT_RETURN (for example).
Investigate why the operand of tree is not evaluated as boolean expression which results in no optimization for 3 cases below. Related method:
optIsBoolComp()
.Paralleize batch of 4+ expressions, e.g.,
x == 0 && y == 0 && z == 0 && w == 0 => (x | y) | (z | w) == 0
Take profile data into account**. If B1's branch is biased away from executing B2 then we might want to skip this optimization or lower the amount we're willing to pay. If B1 is strongly biased towards B2 then we might want to perform this operation even if c2 is more costly (since we're quite likely going to evaluate c2 whether we do this optimization or not).
Check what kind of diffs there are if we eliminate this cost check. That is, is 12 the right number, and why?
Consider optimizing the case we have more than the max number of returns, and create a single return block.
To check if
comp->fgUpdateLoopsAfterCompacting(b1, b3);
updates the loop table.category:cq
theme:basic-cq
skill-level:beginner
cost:small
The text was updated successfully, but these errors were encountered: