These attributes were originally introduced as part of the SYCL upstreaming effort to enable improved performance for USM pointers on FPGA targets. However, subsequent evaluation indicates that they are not meaningfully used in practice. Additionally given the current shift in focus away from FPGAs in DPC++, these attributes no longer serve an active purpose. Their removal would simplify the codebase and reduce ongoing maintenance burden.
Historical Context
SYCL reuses OpenCL address space attributes and previously introduced two additional attributes - opencl_global_device and opencl_global_host as refinements of the global address space.
A preliminary code search suggests that usage of these attributes is limited -
Observed usage is primarily in:
• oneAPI (has indicated support for removal)
• triSYCL (includes references - matching oneAPI - to the attributes. However, based on its documentation, it is a fork of the oneAPI compiler and is no longer actively maintained).
We are not aware of other active downstream users, though this may not be exhaustive.
This RFC is intended to solicit feedback from the community regarding any additional use cases or potential downstream impact that may not be immediately visible.
Based on the limited use in the wild, shift in focus in the downstream, and the oddity that these are named opencl_ but are used for SYCL, I think it’s reasonable to deprecate and eventually remove the attributes. However, I don’t think outright immediate removal is warranted; users should have a transition period unless these attributes are unusably broken or otherwise dangerous (particularly because we explicitly documented our support for these attributes).
CC @svenvh for OpenCL perspective just to make sure these are not used outside of SYCL somewhere.
Thanks for the ping! No concerns from an OpenCL perspective; I have never seen this in the wild in OpenCL content either.
A related question (not blocking this RFC) is whether the removal of these attributes can be cascaded down to the SPIRV-LLVM-Translator? I see we currently have ATTR_GLOBAL_DEVICE and ATTR_GLOBAL_HOST there, which I assume relate to the same attributes?
Sure. That makes sense. If the RFC is accepted, I can put up a PR for deprecation and not submit the PR for removal right now. How long is the transition period usually?
Oh I see. Do you believe these attributes warrant a 1 year removal timeline? To be honest, I do not think these attributes are used at all. However I cannot be 100% certain. I do not think keeping it in the compiler for a year is harmful though, so we could if that is the guideline. @tahonermann would you be ok with that?
I think that’s fine. Less than ideal, but fine. It just means that we’ll need to remember to merge the removal PR after the release of Clang 23 around September.
I’m not sure what that implies for removal of support from the LLVM SPIR-V translator. If we presume no actual existing usage, then no synchronization should be required.
I don’t know one way or the other. I don’t see evidence that they’re being used in practice, and so a shorter period seems defensible, but it also takes time for the compiler to get distributed to users so shortening the period means we run a higher risk of breaking users. It boils down to risk analysis, basically.
(FWIW, I don’t insist on a year-long deprecation period; if the folks with more expertise in this area want to advocate for something different, I think that’s worth discussing.)
Just to clarify. By “a 1 year removal timeline”, I interpret that as deprecating the feature for the next Clang release (e.g., Clang 23) and then removing it in the following release (e.g., Clang 24). The 1 year timeframe therefore reflects the approximate period until the removal is included in a formal Clang release, not the period until the removal PR is merged (which in this case could happen immediately after Clang 23 branches with the deprecation changes included).
Nope, what I meant was that we usually leave something deprecated for two releases (this way we cover folks who follow ToT as well as folks who follow official releases). But if we wanted to shorten that in this instance to one release before removal, that may be reasonable.
But if we wanted to shorten that in this instance to one release before removal, that may be reasonable.
Yes, please.I think one release where it is deprecated and removed in the following release suffices for this we-don’t-think-anyone-actually-uses-it feature.
Yes, unfortunately. It is sad that all the FPGA vendors have given up on supporting modern C++ on their platform. So, I have no concern about removing this.
This RFC was accepted in this message.