================
@@ -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");
----------------
AlexVlx wrote:
If you are removing an antipattern, the replacement is “don't do this”? Not all
things that exists are valid. We should absolutely remove this, at least for
HIP, where it creates needless divergence from CUDA and is a bug farm as a
consequence.
Orthogonally, what are the uses for it that you have in mind, and which
non-offloading languages are you thinking of? The only scenario I can envision
here is if one does an end-to-end compile (so not the weird 1-per-target thing
we do with offload, and not playing games around single AST that gets forked at
CodeGen time). In that case, yes, that *might* be useful, but delivering it as
a macro is fundamentally a bad design IMHO, so even there we should not have
this. Furthermore, at the moment, that sort of use is incredibly underspecified
/ governed by happens to work by accident rather than by design, so building
some early technical debt seems problematic, at least to me
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
