ssahasra wrote: > > Do you see any problem with informing the user that the function `fence()` > > should be redefined with a `__memory_scope` argument instead of `int`? > > You would need to update the current usage in libc, libclc, and openmp and > probably wherever else someone uses this in a function.
libc, libclc and openmp are in-tree projects, so it's conceivable that we can fix the warning for them all. But the next thing is not so easy. > It's not intuitive because why should this warning apply to the memory scope > and not the order? And we can't change the former because it would break > compatibility with GCC. One could argue that scoped atomics are not in GCC, so we are free to set the precedent for both order and scope. But I don't see that as a very good option right now. We could define an enum for order and not warn about it, but that also doesn't achieve much. If an enum only for scope is deemed too inconsistent, then my only other option is to turn the HIP scopes into enums: 1. Introduce `__hip_memory_scope`. 2. Redefine the HIP preprocessor macros to map to this new enum, all that all HIP code silently starts using it. 3. For new scoped `__builtin_amdgcn_*` builtins, make it an error to use this enum. 4. Separately define a deprecation process where `_hip_atomic_*` builtins start emitting warnings and eventually move to an error. The key goal is the ability to error out when the wrong scope is passed to the AMDGPU builtins. https://github.com/llvm/llvm-project/pull/185408 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
