[llvm-branch-commits] [clang] [Clang] define memory scopes as a builtin enum (PR #185408)

[Sameer Sahasrabuddhe via llvm-branch-commits]

ssahasra wrote:

> The key goal is the ability to error out when the wrong scope is passed to the AMDGPU builtins.

I had a good look at C enums, and I believe I have been over-engineering the solution. In C, an enum is just a collection of named integers. So it is quite permissive about conversions between enum and int. On the other hand, implicit conversion between two different enums is a doubtful situation. Clang helpfully warns when this happens, and GCC also warns but only if `-Wenum-conversion` is on.

I think it is sufficient to rely on this behaviour as a helpful safety net when using memory scopes.

1. Create the language-specific `__memory_scope` enum as defined here. But remove the proposed warnings.
2. Separately introduce a `__hip_memory_scope` enum, again without any new warnings.
3. Ideally[*], enhance the builtins infrastructure to declare builtins that take an enum type.
4. Declare the `amdgcn` builtins and the language-independent `__scoped_atomic*` builtins with a scope parameter of type `__memory_scope`.
5. Similarly declare HIP builtins with a scope parameter of type `__hip_memory_scope`.
6. Let the existing enum diagnostics do what they usually do. Replicate the same behaviour if custom type checking is unavoidable.

[*] If step 3 becomes a source of delay, then postpone it and do custom type checking in step 6.

Note that in step 4, the actual user-facing documentation does not need to change for `__scoped_atomic` builtins. It can look like an int just like the order parameter. There is no visible change for any user, except when a HIP programmer mistakenly passes a statically identifiable `__hip_memory_scope` value to a `__scoped_atomic` builtin or the proposed `amdgcn` builtins that take a `__memory_scope` parameter. 


https://github.com/llvm/llvm-project/pull/185408