[clang] [Clang][HIP] Deprecate the AMDGCN_WAVEFRONT_SIZE macros (PR #112849)

[Andrey Alekseenko via cfe-commits]

================
@@ -337,9 +337,12 @@ void AMDGPUTargetInfo::getTargetDefines(const LangOptions &Opts,
   if (hasFastFMA())
     Builder.defineMacro("FP_FAST_FMA");
 
-  Builder.defineMacro("__AMDGCN_WAVEFRONT_SIZE__", Twine(WavefrontSize));
-  // ToDo: deprecate this macro for naming consistency.
-  Builder.defineMacro("__AMDGCN_WAVEFRONT_SIZE", Twine(WavefrontSize));
+  Builder.defineMacro("__AMDGCN_WAVEFRONT_SIZE__", Twine(WavefrontSize),
+                      "compile-time-constant access to the wavefront size will "
+                      "be removed in a future release");
+  Builder.defineMacro("__AMDGCN_WAVEFRONT_SIZE", Twine(WavefrontSize),
+                      "compile-time-constant access to the wavefront size will "
+                      "be removed in a future release");
----------------
al42and wrote:

> The problem is that it's not that simple, since the user can easily change the wavefront size by compiling with -mwavefrontsize64.

I assume you are highlighting a problem with parsing the target list? That's a good point.

> I ran into these types of issues myself while working on the RPC interface for the [rpc](https://github.com/llvm/llvm-project/blob/main/libc/shared/rpc.h#L339) interface.

Ah, the new meaning of "running DOOM on GPUs" :smile: :+1: 

> Alternatively you use a template and do runtime dispatch and assume that optimizations will DCE the other code.

That's a nice solution and we are moving into that direction (with AMD's help). Unfortunately, we already template on a lot of things, and doubling the compile time in the most common case (compiling for a single device architecture) would be quite noticeable. So, having a compile-time _thing_ to only instantiate the data structures / functions for the wavefront size we need would still be desirable.

Not saying that the whole SPIR-V / JIT thing is bad (having portable binaries would be great, especially the ones using standardized IR), but it's not all upsides.

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