================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to