Z: Fix feature detection for mask results by checking source type - #8076
Merged
hzongaro merged 1 commit intoDec 14, 2025
Merged
Conversation
Spencer-Comin
approved these changes
Dec 11, 2025
Contributor
Author
|
I started a jenkin build/test and will run it on a z13 grinder. |
r30shah
suggested changes
Dec 12, 2025
r30shah
left a comment
Contributor
There was a problem hiding this comment.
I think changed are good. Nice catch @Spencer-Comin / @ehsankianifar.
Some nitpicks.
| case TR::vcmpge: | ||
| // Since these opcodes produce a mask as the result type, we need to verify the source type and ensure that | ||
| // the CPU supports the requested feature. | ||
| return cpu->supportsFeature(OMR_FEATURE_S390_VECTOR_FACILITY_ENHANCEMENT_1) |
Contributor
There was a problem hiding this comment.
Can you change the order, I think it reads better. If the opcode is not float or VFE1 is not supported (In case it is float).
| case TR::vcmple: | ||
| case TR::vcmpgt: | ||
| case TR::vcmpge: | ||
| // Since these opcodes produce a mask as the result type, we need to verify the source type and ensure that |
Contributor
There was a problem hiding this comment.
Can you wrap the comment / shorten it.
Mask types were changed to use int32 and int64 instead of float and double, which caused capability checks to fail when the result was a mask and the CPU lacked floating‑point vector support on IBM Z platform. The logic now uses the source vector type when the result is a mask, ensuring feature requirements are correctly determined based on operand semantics. This prevents false negatives and restores accurate feature gating without affecting non‑mask operations. signed-off-by: Ehsan Kiani Far <ehsan.kianifar@gmail.com>
ehsankianifar
force-pushed
the
Z_UseCorrectTypeForSupportChecks
branch
from
December 12, 2025 13:52
3f2c26f to
2d4293b
Compare
hzongaro
self-requested a review
December 12, 2025 20:00
Contributor
|
Jenkins build zos,zlinux |
gita-omr
approved these changes
Dec 13, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Mask types in vector operations were changed to use int32 and int64 instead of float and double. This caused feature checks to fail when the result was a mask and the CPU lacked floating‑point vector support. @Spencer-Comin discovered this issue during IBM Z test runs.
The solution is to check the source vector type when the result is a mask, ensuring feature requirements reflect operand semantics rather than mask representation. This restores correct gating for operations like vector compares that produce masks but depend on FP support in their inputs.
Tests were updated to cover CPUs with and without FP vector support, confirming previously failing cases now pass. Non‑mask operations and integer-only vectors remain unaffected.
@r30shah @gita-omr @hzongaro Please review this PR. This bug is causing failures in upstream tests on Z13.