[clr] Allow 32-bit warp-sync masks on wave32 architectures - #8385
[clr] Allow 32-bit warp-sync masks on wave32 architectures#8385iassiour wants to merge 1 commit into
Conversation
❌ PR Check — Action Required
📖 Need help? See the Policy FAQ for details on every check and how to fix failures. |
|
🚫 Please fix the failed policies before requesting reviews. The following policy checks failed:
The |
There was a problem hiding this comment.
Pull request overview
This PR updates HIP’s warp-sync builtins to permit a 32-bit lane mask on wave32-class targets (instead of requiring a 64-bit integer mask everywhere), and adds a unit test intended to validate __shfl_sync behavior with a 32-bit mask.
Changes:
- Relax
MaskTstatic-assert validation inamd_warp_sync_functions.hto allow 32-bit masks on specific targets. - Add a new HIP test kernel + Catch2 test case to validate
__shfl_syncwith a 32-bit mask. - Register the new test in the warp unit test YAML config.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| projects/hip-tests/catch/unit/warp/hipShflSyncTests.cc | Adds a new kernel and test case for __shfl_sync mask-type acceptance and broadcast correctness. |
| projects/hip-tests/catch/config/configs/unit/warp.yaml | Registers the new unit test in the warp test suite. |
| projects/clr/hipamd/include/hip/amd_detail/amd_warp_sync_functions.h | Adjusts mask type validation to permit 32-bit masks under a target-specific compile-time guard. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
1bee26e to
dda6258
Compare
|
If we do this, for consistency, all the __reduce_sync operations should also allow a 32-bit mask |
e93c3f7 to
5b56230
Compare
3f6e43f to
bf8bce3
Compare
bf8bce3 to
00efd15
Compare
|
Keeping the mask argument independent of wavesize was a deliberate decision. The mask is always 64-bit so that a single HIP source will compile correctly to any target. Perhaps we need a deeper understanding of the need for a 32-bit mask. Is it just convenience? Or a real issue? Even if it is just convenience, how important is it? |
I think this is covered by the changes in reduce_op_sync https://github.com/ROCm/rocm-systems/pull/8385/changes#diff-c885872acc0fe466252f4a87941bfc669032ba494f1107cbd020e94e2847ac4bR327 But modified the test to cover the case as well |
|
closing based on the comments on https://amd-hub.atlassian.net/browse/ROCM-27352 |
Motivation
Allow 32-bit warp-sync masks on wave32 AMD targets. Code such as:
__shfl_sync(0xffffffff, value, 0, width)
currently fails to compile because HIP requires every explicit warp-sync mask to be a 64-bit integer, even on wave32 architectures where a 32-bit mask is the natural width.
Technical Details
Replaces the duplicated sizeof(MaskT) == 8 checks in amd_warp_sync_functions.h with a shared mask-type predicate.
Allows 32-bit integer masks for wave32-only targets covered by this change while keeping the existing 64-bit requirement for other device targets.
Leaves the existing runtime behavior intact: wave32 masks still ignore the upper half via __hip_adjust_mask_for_wave32.
Adds Unit_hipShflSync_32BitMask to validate that __shfl_sync accepts a 32-bit mask and broadcasts lane 0 correctly.
JIRA ID
Resolves ROCM-27352.
Test Plan
Compile raw 32-bit-mask repro for gfx1250/gfx942/gfx950.
Compile the new guarded unit test for gfx1250/gfx942/gfx950.
Run existing CI.
Test Result
Raw 32-bit mask compiles for wave32 targets covered by this change.
Raw 32-bit mask remains rejected on gfx942/gfx950 wave64 targets.
New Unit_hipShflSync_32BitMask syntax-checks cleanly for gfx1250/gfx942/gfx950.
Submission Checklist