-
Notifications
You must be signed in to change notification settings - Fork 754
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
[SYCL] [NATIVECPU] Implement generic atomic store for generic target #13428
Conversation
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, thanks
@frasercrmck I've just realized that after #13109, |
The previous model where we declare/define builtins based on whether target supports the generic address space was not able to capture the full complexity of what we need. We could see this in the fact that the two targets which we marked as not supporting the generic AS do in fact support it. The problem is rather that the target AS they map the generic AS to is the same target AS mapped to by the private AS. This problem hasn't properly been made apparent because all builtins we want to support with the generic AS also have overloads on the private AS. However, as can be seen in PRs like #13428, some targets want to support generic AS overloads of atomic builtins which don't also have private AS overloads. It's here that the simple dichotomy breaks down. This patch splits up the support of the generic AS into: 1. The target doesn't support the generic AS 2. The target supports the generic AS as a distinct target AS 3. The target supports the generic AS mapped identically as the private the AS All of our previous uses of case 1 have been migrated to case 3. These targets can make use of case 2 in the future to support generic AS builtins where no private AS builtins are supported. Note how we hardcode the assumption that the clash is on the private address space. This is unfortunate but for simplicity as it's the case for the two targets we care about. It was already being made, but in a less obvious way. There are ways of loosening this assumption if we ever needed to but it would currently complicate the code for untested scenarios.
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.
LGTM
@intel/llvm-gatekeepers this looks ready to merge, thank you |
Following up to #13428, this PR implements the overloads for the generic AS that are missing in the `generic` libclc target.
Implements
__spirv_AtomicStore
similarly to #13249. Note that theIMPL
macro has been extended to take in aSUB
parameter, similarly to what happens for amdgcn and ptx.