[SYCL] Refactor address space casts functionality #15543
Conversation
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
aelovikov-intel
force-pushed
the
refactor-as-casts
branch
from
72d1735 to
63667f0
Compare
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Error
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Error
aelovikov-intel
force-pushed
the
refactor-as-casts
branch
from
63667f0 to
2537fbc
Compare
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Error
multi_ptr(accessor) - correct AS is guaranteed by SFINAE explicit operatr multi_ptr<...> - UB if mismatch TODO: constant_space ?
aelovikov-intel
force-pushed
the
refactor-as-casts
branch
from
2537fbc to
261dddf
Compare
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Error
There was a problem hiding this comment.
See https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/experimental/sycl_ext_oneapi_prefetch.asciidoc, it states (for non-accessor overloads):
Preconditions: ptr must point to an object in global memory.
| auto DestP = multi_ptr<uint8_t, DestS, access::decorated::yes>( | ||
| detail::cast_AS<typename multi_ptr<uint8_t, DestS, | ||
| access::decorated::yes>::pointer>( | ||
| reinterpret_cast<typename multi_ptr<uint8_t, DestS, |
There was a problem hiding this comment.
We're changing element type of the decorated C++ pointer type here, no address space changes. Same throughout this file.
| auto DestP = multi_ptr<uint8_t, DestS, access::decorated::yes>( | ||
| detail::cast_AS<typename multi_ptr<uint8_t, DestS, | ||
| access::decorated::yes>::pointer>( | ||
| reinterpret_cast<typename multi_ptr<uint8_t, DestS, |
There was a problem hiding this comment.
We're changing element type of the decorated C++ pointer type here, no address space changes. Same throughout this file.
| multi_ptr & | ||
| operator=(const multi_ptr<value_type, OtherSpace, OtherIsDecorated> &Other) { | ||
| m_Pointer = detail::cast_AS<decorated_type *>(Other.get_decorated()); | ||
| m_Pointer = detail::static_address_cast<Space>(Other.get_decorated()); |
There was a problem hiding this comment.
"static" cast from non-constant_space to generic_space is always possible.
| multi_ptr & | ||
| operator=(multi_ptr<value_type, OtherSpace, OtherIsDecorated> &&Other) { | ||
| m_Pointer = detail::cast_AS<decorated_type *>(std::move(Other.m_Pointer)); | ||
| m_Pointer = detail::static_address_cast<Space>(std::move(Other.m_Pointer)); |
| isPlaceholder, PropertyListT> | ||
| Accessor) | ||
| : multi_ptr(detail::cast_AS<decorated_type *>( | ||
| : multi_ptr(detail::static_address_cast<Space>( |
There was a problem hiding this comment.
because accessor.
| pointer get() const { return detail::cast_AS<pointer>(m_Pointer); } | ||
| pointer get() const { | ||
| return detail::static_address_cast< | ||
| is_decorated ? Space : access::address_space::generic_space>(m_Pointer); |
There was a problem hiding this comment.
See above - either no-op/identity or cast away decoration.
| static_cast<typename multi_ptr<ElementType, Space, | ||
| access::decorated::yes>::pointer>( |
There was a problem hiding this comment.
Changing element type from void to ElementType, no address space changes.
| typename multi_ptr<void, GlobalSpace, access::decorated::yes>::pointer; | ||
| return multi_ptr<void, GlobalSpace, DecorateAddress>( | ||
| detail::cast_AS<global_pointer_t>(m_Pointer)); | ||
| detail::static_address_cast<GlobalSpace>(m_Pointer)); |
There was a problem hiding this comment.
Subsections of the global_space per definition, known to succeed.
|
|
||
| multi_ptr(ElementType *pointer) | ||
| : m_Pointer(detail::cast_AS<pointer_t>(pointer)) { | ||
| : m_Pointer(detail::dynamic_address_cast< |
There was a problem hiding this comment.
See comment near the definition of detail::dynamic_address_cast, that part is mostly NFC. The exception is non-SPIRV backends when we know that address spaces are NOT compatible. Previously we were doing C-style cast anyway, now nullptr is returned.
Same for ctors below.
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Error
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
| return Ptr; | ||
| else | ||
| return {static_address_cast<Space>(Ptr.get_raw())}; | ||
| return {static_address_cast<Space>(Ptr.get_decorated())}; |
There was a problem hiding this comment.
We were limited by the extension interface before, so had to drop this bit of information in order to delegate. Now that we're calling something from detail:: we can keep decoration in place.
aelovikov-intel
changed the title
aelovikov-intel
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
aelovikov-intel
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
Apparently, we perform some hacks around constant address space that I wasn't aware of. Make sure new address cast helpers are called consistently with the previous behavior.
Apparently, we perform some hacks around constant address space that I wasn't aware of. Make sure new address cast helpers are called consistently with the previous behavior. --------- Co-authored-by: Sergey Semenov <[email protected]>
This became possible sometime after one/all of * intel#15394 * intel#15543 * intel#16604
3 participants
This follows the interfaces designed in https://github.com/intel/llvm/blob/3a1c3cb53566f904a73361d5c57b939d981564b5/sycl/doc/extensions/proposed/sycl_ext_oneapi_address_cast.asciidoc, but instead of operating on
multi_ptr, these work on decorated C++ pointers (as that's what we need throughout our implementation, includingmulti_ptrimplementation itself).Basically, I've moved the implementation of the extension to the new
detail::static|dynamic_address_castfunctions and replaced all uses of the olddetail::cast_AS(that had inconsistent static vs dynamic behavior depending on address spaces/backends) and also uses of direct SPIRV builtin/wrappers invocations.This isn't NFC, because by doing that I've changed "dynamic" behavior to "static" whenever the spec allows that (e.g. if it's UB if runtime pointers doesn't point to a proper allocation).