KhronosGroup / KhronosGroup/SYCL-Docs
`get_multi_ptr` has no default `access::decorated` param: leads to unnecessarily complex code
- Dominant language
- JavaScript
- Stars
- 158
- Forks
- 80
- Avg merge
- 7d 6h
- Merged PRs (30d)
- 5
Description
Currently in SYCL even when primarily using USM, you have to work with accessors in order to use shared local memory. Currently the spec does not define a default for the `access::decorated` template parameter of this function.
This leads to, instead of the previous `accessor.get_multi_ptr()`, the following code `accessor.template get_multi_ptr()` as e.g. here:
https://github.com/intel/llvm/pull/8874/files#diff-d786889741a6036c68c767d56f993becedda2253cd98780bf528798c24e38e18R61
Due to how commonly such code has to be written I think this is a very high priority issue.
The fix to this requires a spec change to define a default: basically this patch: https://github.com/intel/llvm/pull/9735
It seems that `decorated::no` is the correct default choice: So far noone has given a reason for why `access::decorated` needs to be a template argument for `multi_ptr` in the first place: if a sycl implementation requires a decorated pointer, then the implementation can create this since the address space is already a template argument for `multi_ptr`: as it already does in this code https://github.com/intel/llvm/pull/9244/files#diff-e5457c55cc4c6ae06dcc828220b499fd4e55a1e3f7755a27c34da20f636c86ceR83
Presumably the idea is that a user can specialize their own code based on the address space of the pointer, but again, I don't see why in such a case they can't just get the address space from the `multi_ptr`?
**A related issue:**
If there is a reason for exposing `decorated` to the user in the sycl spec, then surely this justification should also be described in the specification, with a simple example. Currently in the latest sycl spec there is no such explanation for `access::decorated`. This is despite the fact that the string "decorate" appears 274 times in the spec.
If there is no good reason for exposing this to users then it should be removed from the spec.
The more unnecessarily complicated and confusing the SYCL specification is, the harder it is for people to adopt it, which will put off potential adopters of SYCL.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the SYCL specification sections covering get_multi_ptr and access::decorated, then compare the proposed change in pull request 9735 with the related examples in pull requests 8874 and 9244. Done means the specification either defines the default unambiguously or explains, with an example, why decorated must remain user-visible.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- documentation
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100