[clang] [Clang][HIP] Deprecate the AMDGCN_WAVEFRONT_SIZE macros (PR #112849)
Alex Voicu via cfe-commits
cfe-commits at lists.llvm.org
Sun Oct 20 07:31:15 PDT 2024
================
@@ -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
More information about the cfe-commits
mailing list