Skip to content

Correct Mask unboxing in VectorAPIExpansion #21743

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
May 8, 2025
Merged

Correct Mask unboxing in VectorAPIExpansion #21743

merged 1 commit into from
May 8, 2025

Conversation

gita-omr
Copy link
Contributor

@gita-omr gita-omr commented Apr 28, 2025 •
edited
Loading

  • use the same code as for loading a mask from an array

Depends on: eclipse-omr/omr#7737

@gita-omr
Copy link
Contributor Author

@BradleyWood fyi

@dsouzai dsouzai self-assigned this Apr 28, 2025
@gita-omr gita-omr requested a review from dsouzai April 29, 2025 01:36
dsouzai
dsouzai requested changes Apr 29, 2025
View reviewed changes
Copy link
Contributor

@dsouzai dsouzai left a comment

Choose a reason for hiding this comment

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

Overall looks fine to me; minor refactoring suggested.

runtime/compiler/optimizer/VectorAPIExpansion.cpp Outdated
Comment on lines 1562 to 1566
(operandObjectType == Mask &&
!isOpCodeImplemented(comp(),
(maskConv = getLoadToMaskConversion(numLanes,
TR::DataType::createMaskType(elementType, vectorLength),
maskLoadOpCode)))))
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this is far too complicated to put as a condition in an if statement; probably best to to refactor it out (especially since it's guarded by operandObjectType == Mask &&).

@dsouzai
Copy link
Contributor

dsouzai commented Apr 29, 2025

@BradleyWood could you review from a code pov?

BradleyWood
BradleyWood reviewed Apr 29, 2025
View reviewed changes
Copy link
Member

@BradleyWood BradleyWood left a comment

Choose a reason for hiding this comment

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

I guess my biggest complaint is that you address unboxing without fixing mask boxing. I don't really see it as much extra effort.

runtime/compiler/optimizer/VectorAPIExpansion.cpp Outdated
parentScalarized || // TODO: support unboxing into scalars
(operandObjectType == Mask &&
!isOpCodeImplemented(comp(),
(maskConv = getLoadToMaskConversion(numLanes,
Copy link
Member

Choose a reason for hiding this comment

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

I think if the load is a vector, you need to check support for the vload. I did find this expression hard to follow. For instance, you assign maskLoadOpCode inside the function call getLoadToMaskConversion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, I will simplify it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don't check for vload in several other places. I guess we assume that if a platform supports vectorization (check at the beginning of this opt) then vload/vstore are supported.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Simplified the code.

runtime/compiler/optimizer/VectorAPIExpansion.cpp
bitsLength != 128 ||
parentScalarized) // TODO: support unboxing into scalars
elementType != TR::Int8 || // TODO: support more types (needs support in createClassesForBoxing)
bitsLength != 128 ||
Copy link
Member

Choose a reason for hiding this comment

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

any reason to limit this to 128-bit?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, we need to create class objects for all other types. I would like to give it a thought on what's the best way to do it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The TODO comment explains why only 128-bit.

@gita-omr
Copy link
Contributor Author

I guess my biggest complaint is that you address unboxing without fixing mask boxing. I don't really see it as much extra effort.

I prefer to make incremental changes in this case.

@gita-omr
Copy link
Contributor Author

Made dependent on eclipse-omr/omr#7737 since we replaced mloadi with v2m for unboxing and we would like unboxing to work on Power (for a start).

@gita-omr
Copy link
Contributor Author

Just wanted to note that Vector API boxing/unboxing is currently not enabled by default. The whole feature is still WIP with many remaining todos.

@gita-omr
Correct Mask unboxing in VectorAPIExpansion
891688d 
- use the same code as for loading a mask from an array
@gita-omr
Copy link
Contributor Author

gita-omr commented May 1, 2025

Addressed comments above.

dsouzai
dsouzai approved these changes May 5, 2025
View reviewed changes
Copy link
Contributor

@dsouzai dsouzai left a comment

Choose a reason for hiding this comment

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

LGTM; will wait for @BradleyWood's OK.

@dsouzai dsouzai added depends:omr Pull request is dependent on a corresponding change in OMR arch:power comp:jit labels May 5, 2025
@dsouzai
Copy link
Contributor

dsouzai commented May 5, 2025

jenkins test sanity all jdk21 depends eclipse-omr/omr#7737

@dsouzai
Copy link
Contributor

dsouzai commented May 5, 2025 •
edited
Loading

Running tests pre-emptively; but won't be able to merge until either the OMR PR gets merged (which is contingent on the OMR Jenkins instance being operational or the change is verified with some internal/personal build).

Testing all because the change here is common code.

@dsouzai
Copy link
Contributor

dsouzai commented May 6, 2025

Only failure due to known issue:

[2025-05-05T22:46:44.043Z] Test result: FAILED
[2025-05-05T22:46:44.043Z] Output from test:
[2025-05-05T22:46:44.043Z]  [OUT] start running script
[2025-05-05T22:46:44.043Z]  [OUT] export GLIBC_TUNABLES=glibc.cpu.hwcaps=-XSAVEC,-XSAVE,-AVX2,-ERMS,-AVX,-AVX_Fast_Unaligned_Load
[2025-05-05T22:46:44.043Z]  [OUT] export LD_BIND_NOT=on
[2025-05-05T22:46:44.043Z]  [OUT] Starting /home/jenkins/workspace/Test_openjdk21_j9_sanity.functional_x86-64_linux_Personal_testList_0/jdkbinary/j2sdk-image/bin/jitserver -XX:JITServerPort=43217 -XX:JITServerHealthProbePort=53634 
[2025-05-05T22:46:44.043Z]  [OUT] JITSERVER DOES NOT EXIST
[2025-05-05T22:46:44.043Z]  [OUT] finished script
[2025-05-05T22:46:44.043Z]  [ERR] /home/jenkins/workspace/Test_openjdk21_j9_sanity.functional_x86-64_linux_Personal_testList_0/aqa-tests/TKG/../../jvmtest/functional/cmdLineTests/criu/jitserverconfig.sh: line 30: lsof: command not found
[2025-05-05T22:46:44.043Z]  [ERR] /home/jenkins/workspace/Test_openjdk21_j9_sanity.functional_x86-64_linux_Personal_testList_0/aqa-tests/TKG/../../jvmtest/functional/cmdLineTests/criu/jitserverconfig.sh: line 30: lsof: command not found
[2025-05-05T22:46:44.043Z]  [ERR] can't bind server address: Address already in use
[2025-05-05T22:46:44.043Z]  [ERR] Failed to open health socket on port 53634

This PR is ok to merge once the OMR PR gets merged.

@dsouzai
Copy link
Contributor

dsouzai commented May 6, 2025

Merged the OMR PR; will need to wait until it propagates to openj9-omr before I merge this one.

@dsouzai
Copy link
Contributor

dsouzai commented May 8, 2025

Dependent OMR changes have propagated to openj9-omr; merging.

@dsouzai dsouzai merged commit 9ce6972 into eclipse-openj9:master May 8, 2025
25 of 27 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dsouzai dsouzai dsouzai approved these changes

+1 more reviewer

@BradleyWood BradleyWood BradleyWood approved these changes

Reviewers whose approvals may not affect merge requirements
Assignees

@dsouzai dsouzai

Labels
arch:power comp:jit depends:omr Pull request is dependent on a corresponding change in OMR
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@gita-omr @dsouzai @BradleyWood