-
Notifications
You must be signed in to change notification settings - Fork 5.2k
JIT: Fold "cmp & 1" to "cmp" #52524
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: Fold "cmp & 1" to "cmp" #52524
Conversation
|
@dotnet/jit-contrib @BruceForstall 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.
| } | ||
|
|
||
| // Fold "cmp & 1" to just "cmp" | ||
| if (tree->OperIs(GT_AND) && tree->TypeIs(TYP_INT) && op1->OperIsCompare() && op2->IsIntegralConst(1)) |
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.
sorry, I am late for the review, two questions:
- do we want to do it when optimizations are disabled?
- Can op2 or tree be a CSE candidates that we destroy while CSE is keeping links on them?
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 found plenty of such small peepholes in morph without
OptimizationEnabledguard so it wasn't clear to me when we should really apply it - I guess we want to eventually have three different modes: MinOpts, tier0 (simple opts) and tier1 (all opts). -
op2 is always an integer const (1) and CSE doesn't work for them without a special switch -- so it's not a correct behavior to delete a potential CSE candidate and it might lead to a crash/assert?
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.
op2 is always an integer const (1) and CSE doesn't work for them without a special switch -- so it's not a correct behavior to delete a potential CSE candidate and it might lead to a crash/assert?
the switch is on for arm64 but tree can be a CSE candidate without it. I would recommend adding a change to protect against it.
I noticed this pattern after loop clonning (it produces it for the condition for two loops), e.g.:
Codegen diff: https://www.diffchecker.com/fdGIQqQJ
(Obviously, for this specific method the clonned loop should either be removed or not emitted in the first place but that is a different story)
SuperPMI diffs: