[clang] [Clang][NVPTX] fix `no member named 'this_cluster'` (PR #187039)

[Artem Belevich via cfe-commits]

================
@@ -184,6 +184,12 @@ void NVPTXTargetInfo::getTargetDefines(const LangOptions &Opts,
     unsigned ArchID = CudaArchToID(GPU);
     Builder.defineMacro("__CUDA_ARCH__", llvm::Twine(ArchID));
 
+    // Per
+    // https://docs.nvidia.com/cuda/cuda-programming-guide/04-special-topics/cooperative-groups.html#id4
+    // clusters are only available with >=9.0 compute capability
+    if (ArchID >= 900)
+      Builder.defineMacro("_CG_CLUSTER_INTRINSICS_AVAILABLE");
----------------
Artem-B wrote:

On the second thought, I do not think this macro should be defined by compiler itself.

AFAICT, nvcc does not define it: https://godbolt.org/z/WMhfPKWM9

The code in CUDA appears to use it as an escape hatch to force the availability check):
```
#if ((_CG_CUDA_ARCH >= 900) || !defined(_CG_CUDA_ARCH)) && \
    (defined(__NVCC__) || defined(__CUDACC_RTC__) || defined(_CG_CLUSTER_INTRINSICS_AVAILABLE)) && \
    defined(_CG_CPP11_FEATURES)
# define _CG_HAS_CLUSTER_GROUP
#endif
```

As such, defining this macro would be a job better suited for https://github.com/llvm/llvm-project/blob/main/clang/lib/Headers/__clang_cuda_runtime_wrapper.h where we are dealing with other quirks of CUDA headers.

Also, the fact that the headers already enforce the check of architecture implies that `_CG_CLUSTER_INTRINSICS_AVAILABLE` is more of a "does compiler support those intrinsics in general?" (i.e. "is it nvcc?") but not necessarily that they are available in this particular compilation with given options.

The bottom line is that I think that it should be a plain `#define _CG_CLUSTER_INTRINSICS_AVAILABLE 1` in  _clang_cuda_runtime_wrapper.h


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