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

[SYCL] Use static address space cast for atomic_ref ctor in SPIR-V path #15384

Merged
merged 11 commits into from
Sep 18, 2024

Conversation

aelovikov-intel
Copy link
Contributor

From SYCL 2020 specification:

The sycl::atomic_ref class also has a template parameter AddressSpace,
which allows the application to make an assertion about the address
space of the object of type T that it references. The default value
for this parameter is access::address_space::generic_space, which
indicates that the object could be in either the global or local
address spaces. If the application knows the address space, it can set
this template parameter to either access::address_space::global_space
or access::address_space::local_space as an assertion to the
implementation. Specifying the address space via this template
parameter may allow the implementation to perform certain
optimizations. Specifying an address space that does not match the
object’s actual address space results in undefined behavior

We use ext::oneapi::experimental::static_address_cast to do that. It's
not implemented for CUDA/HIP yet, that path continues using
sycl::address_space_cast that performs runtime checks:

An implementation must return nullptr if the run-time value of pointer
is not compatible with Space, and must issue a compiletime diagnostic
if the deduced address space for pointer is not compatible with Space.

…V path

From SYCL 2020 specification:

> The sycl::atomic_ref class also has a template parameter AddressSpace,
> which allows the application to make an assertion about the address
> space of the object of type T that it references. The default value
> for this parameter is access::address_space::generic_space, which
> indicates that the object could be in either the global or local
> address spaces. If the application knows the address space, it can set
> this template parameter to either access::address_space::global_space
> or access::address_space::local_space as an assertion to the
> implementation. Specifying the address space via this template
> parameter may allow the implementation to perform certain
> optimizations. Specifying an address space that does not match the
> object’s actual address space results in undefined behavior

We use `ext::oneapi::experimental::static_address_cast` to do that. It's
not implemented for CUDA/HIP yet, that path continues using
`sycl::address_space_cast` that performs runtime checks:

> An implementation must return nullptr if the run-time value of pointer
> is not compatible with Space, and must issue a compiletime diagnostic
> if the deduced address space for pointer is not compatible with Space.
// CHECK-LABEL: define dso_local spir_func noundef i32 @_Z17atomic_ref_globalRi(
// CHECK-SAME: ptr addrspace(4) noundef align 4 dereferenceable(4) [[I:%.*]]) local_unnamed_addr #[[ATTR0:[0-9]+]] !srcloc [[META6:![0-9]+]] !sycl_fixed_targets [[META7:![0-9]+]] {
// CHECK-NEXT: [[ENTRY:.*:]]
// CHECK-NEXT: [[CALL_I_I_I_I_I_I:%.*]] = tail call spir_func noundef ptr addrspace(1) @_Z33__spirv_GenericCastToPtr_ToGlobalPvi(ptr addrspace(4) noundef [[I]], i32 noundef 5) #[[ATTR3:[0-9]+]]
Copy link
Contributor Author

Choose a reason for hiding this comment

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

One can review individual commits in this PR to see before/after change.

SPIRV operations are defined such that `OpGenericCastToPtr` and
`OpGenericCastToPtrExplicit` cannot be used when target `Storage Class`
is `Generic`, yet we were generating such code. This PR fixes that.
@maarquitos14
Copy link
Contributor

@aelovikov-intel I see you marked this as draft. Is this good to review or is it still work in progress?

@aelovikov-intel aelovikov-intel marked this pull request as ready for review September 16, 2024 15:34
@aelovikov-intel
Copy link
Contributor Author

@aelovikov-intel I see you marked this as draft. Is this good to review or is it still work in progress?

Ready now. I had to wait until #15394 is merged and this is updated to include it via origin/sycl.

@@ -157,8 +158,16 @@ class atomic_ref_base {
}

#ifdef __SYCL_DEVICE_ONLY__
#if defined(__SPIR__)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is feature test macro SYCL_EXT_ONEAPI_ADDRESS_CAST not defined for the __SPIR__ case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Extension implementation seems to have missed that completely. I'm making other changes to the extension, will work on that outside this PR.

Copy link
Contributor

@maarquitos14 maarquitos14 left a comment

Choose a reason for hiding this comment

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

LGTM.

@aelovikov-intel aelovikov-intel merged commit 0b65c98 into intel:sycl Sep 18, 2024
12 checks passed
@aelovikov-intel aelovikov-intel deleted the atomic-ref-static-as-cast branch September 18, 2024 17:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants