Skip to content
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 the return type of VectorSupport.fromBitsCoerced #16330

Merged

Conversation

Akira1Saitoh
Copy link
Contributor

The return type of jdk_internal_vm_vector_VectorSupport_fromBitsCoerced can be either of Vector or Mask.
Change the type field of the fromBitsCoerced entry in the method table to unknown and update visitNodeToBuildVectorAliases to get the correct type for the call by checking the value of the 5th child node.

Signed-off-by: Akira Saitoh saiaki@jp.ibm.com

@Akira1Saitoh
Copy link
Contributor Author

@gita-omr Can you please review this? Thanks.

}
else if (methodSymbol->getRecognizedMethod() == TR::jdk_internal_vm_vector_VectorSupport_fromBitsCoerced)
{
TR::Node *broadcastTypeNode = node->getChild(4);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have not done it before, but I think it would be nice to start using some class scope constants to define position of different parameters in the intrinsics, eg static int_32 const BROADCAST_TYPE_CHILD = 4 in the header.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. Added the constant BROADCAST_TYPE_CHILD to the class and updated the code to use the constant.

@@ -1810,7 +1830,8 @@ TR::Node *TR_VectorAPIExpansion::fromBitsCoercedIntrinsicHandler(TR_VectorAPIExp

TR::Node *newNode;

switch (elementType) {
int32_t type = mask ? TR::Int64 : elementType;
switch (type) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will we still generate vsplats? Maybe we need to introduce msplats?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When broadcastType == MODE_BITS_COERCED_LONG_TO_MASK, opcode we generate is mLongBitsToMask. In that case, the source type of the conversion must be long instead of the element type.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, right, of course, we do generate the right opcode! Then everything looks good to me.

The return type of jdk_internal_vm_vector_VectorSupport_fromBitsCoerced
can be either of Vector or Mask.
Change the type field of the fromBitsCoerced entry in the method table
to unknown and update visitNodeToBuildVectorAliases to get the correct
type for the call by checking the value of the 5th child node.

Signed-off-by: Akira Saitoh <saiaki@jp.ibm.com>
@gita-omr
Copy link
Contributor

Jenkins test sanity all jdk8,jdk11,jdk19

@knn-k knn-k added the comp:jit label Nov 17, 2022
@gita-omr gita-omr merged commit 024f1b3 into eclipse-openj9:master Nov 20, 2022
@Akira1Saitoh Akira1Saitoh deleted the FixTypeOfFromBitsCoerced branch November 20, 2022 07:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants