-
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
Fix a couple issues with Vector128.Get/WithElement #52985
Conversation
CC. @jkotas, @echesakovMSFT |
/azp run runtime-coreclr jitstress-isas-x86 |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, runtime-coreclr outerloop |
Azure Pipelines successfully started running 3 pipeline(s). |
Now failing with:
|
This was because we are cloning a TYP_SIMD12 LclVar in lowering. Lowering "widens" (changes the type) of these to TYP_SIMD16 which causes an assert when the types mismatch on clone. There is also a failure in the logic for |
/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, runtime-coreclr outerloop |
Azure Pipelines successfully started running 3 pipeline(s). |
/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, runtime-coreclr outerloop |
Azure Pipelines successfully started running 3 pipeline(s). |
I am still seeing this failure even with the latest commit. |
Should be resolved now. Both the LclVar and assignment need to be lowered for ReplaceWithLclVar over TYP_SIMD12 nodes. |
/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, runtime-coreclr outerloop |
Azure Pipelines successfully started running 3 pipeline(s). |
/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, runtime-coreclr outerloop |
Azure Pipelines successfully started running 3 pipeline(s). |
@jkotas, all tests are passing now. This should be good now. |
Thank you. I see all tests passing in runtimelab NativeAOT branch - where I found it initially - as well. |
@echesakovMSFT, @dotnet/jit-contrib can I get a review to unblock the failing jitstress/outerloop tests? |
@echesakovMSFT, @dotnet/jit-contrib can I get a review to unblock the failing jitstress/outerloop tests? |
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 am not against unblocking outerloop I am just worried it could create more issues, I suggest disabling the failing test in separate PR and take time to finish this.
// We need to lower the LclVar and assignment since there may be certain | ||
// types or scenarios, such as TYP_SIMD12, that need special handling | ||
|
||
LowerNode(assign); |
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 do not think it is a correct approach, this function is used during different phases, for example, during long decomposition, so calling LowerNode
during it is incorrect.
ReplaceWithLclVar
creates such IR:
currentNode
storeCurrentNodeToNewNode
NewNodeUse
and lowering works node by node, so after we are done with currentNode
we should go to the next and lower it, why don't we?
See, for example, LowerSwitch
runtime/src/coreclr/jit/lower.cpp
Line 504 in b443b8c
ReplaceWithLclVar(use); |
we call
ReplaceWithLclVar
and it creates these new nodes, but then we return node->gtNext
that is the created store:runtime/src/coreclr/jit/lower.cpp
Lines 785 to 791 in b443b8c
GenTree* next = node->gtNext; | |
// Get rid of the GT_SWITCH(temp). | |
switchBBRange.Remove(node->AsOp()->gtOp1); | |
switchBBRange.Remove(node); | |
return next; |
and it does their lowering.
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.
The one used in long decomposition is the instance method exposed on LIR::Use
which is distinct from this method that is explicit to lowering and which itself calls into the LIR::Use
method
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.
and lowering works node by node, so after we are done with currentNode we should go to the next and lower it, why don't we?
We should already have lowered all the previous nodes, we aren't removing the "current" node, and we aren't inserting a node after the "current" node, so the "next" node is already correct. We simply need to ensure new nodes created and inserted before this node are also lowered.
This is how the existing HWIntrinsic and SimdIntrinsics lowering has been handled and so the same technique is used here as well.
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.
We should already have lowered all the previous nodes, we aren't removing the "current" node,
Agree
and we aren't inserting a node after the "current" node, so the "next" node is already correct.
Don't understand, ReplaceWithLclVar
creates new nodes and inserts them after the "current" node, what do you mean?
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.
Don't understand, ReplaceWithLclVar creates new nodes and inserts them after the "current" node, what do you mean?
ReplaceWithLclVar
creates new nodes and inserts them after the node it replaces. In this case, we are replacing an operand of the "current" node, which means it precedes the current node in the list and will already have been lowered.
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 am still reviewing the changes in 1a4e854
But I want to release some comments to speed up the review process
/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm, runtime-coreclr outerloop |
Azure Pipelines successfully started running 3 pipeline(s). |
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.
Looks Good but have some additional questions
Hello @tannergooding! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
This resolves #52959 by ensuring that we don't have any unused nodes and that containment checks bail when encountering TYP_SIMD8 or TYP_SIMD12 values where a TYP_SIMD16 or TYP_SIMD32 value is required for containment.
This resolves #52954 by ensuring the expected exception is the one thrown by all Vector indexing
This resolves #53157
This resolves #37260