standards-proposals
standards-proposals copied to clipboard
codeplaysoftware
CP004: Can Placeholder accessor be default constructible?
Feedback from some users after trying out the placeholder accessors seems to indicate that they should be default constructible, and that the buffer should be assigned later during the requirement setting stage.
Having default constructible accessors would enhance their usability compared to raw pointers. A use case which can benefit from default constructible accessors is the use of an accessor in a C++ class like an iterator. SYCL does not allow to store pointers inside classes used in device code, thus used classes are cannot be default constructible when holding an accessor. However, for the Range TS, iterators passed to views must fulfill the concept of default constructible. Using an std::reference_wrapper will fail on the "no pointers" rule while using an std::optional from C++17 is currently undefined behaviour in the SYCL standard. This issues can be avoided by making placeholder accessors default constructible. A possible solution would be to make allow placeholder accessors to be bound to a particular buffer after their creation directly on the host.
std::vector<value_type> vec;
cl::sycl::buffer<value_type, 1> buf(vec.data(), vec.size());
auto acc = decltype(buf)::get_access<access::mode::read_write, access::target::global,
access::placeholder::true_t>();
buf.bind(acc); // bind the accessor to the buffer
I can see the benefit of having this feature. I think the best approach to supporting this would be to have a default constructor for the accessor class when access::placeholder is true_t and then having a member function which can bind a memory object to the accessor at a later point. My only concern would be in ensuring safe usage of unbound accessors; I would suggest having an additional member function for querying whether an accessor has a valid memory object bound to it such as is_bound, and that any usage of an unbound accessor result in an exception.
