-
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] X64 - Allow containment of larger memory operands for AND
, OR
, XOR
#79126
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue Details** Description ** This PR allows the operators, This is needed to prevent a few regressions from this PR: #77874 ** Acceptance Criteria **
|
@@ -447,6 +444,30 @@ class Lowering final : public Phase | |||
return m_lsra->isContainableMemoryOp(node); | |||
} | |||
|
|||
// Return true if 'childNode' is a containable memory op by its size relative to the 'parentNode'. | |||
// Currently very conservative. | |||
bool IsContainableMemoryOpSize(GenTree* parentNode, GenTree* childNode) const |
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.
Not sure what to name this. IsContainableMemoryOpSize
might be confusing considering we have a IsContainableMemoryOp
already.
@dotnet/jit-contrib ready for review |
Why just and/or/xor and not more generally? We're on a little endian platform so it's safe to just access the lowest n-bits for nearly any operation (add, sub, mul, div, etc) That's what we do for hw intrinsics, presently. |
At the moment, we only change |
Description
This PR allows the operators,
AND
,OR
,XOR
to be able to contain memory operands that are of larger size than the operator itself. There is only a single case where we use a small type for those operators, it happens when trying to take advantage of CPU flags for aJCC
on x86/x64.This is needed to prevent a few regressions from this PR: #77874
Example diffs:
Acceptance Criteria