Artem-B wrote: > This patch checks for numeric literals in clearly identifiable host code if > they are the result of expanding the wavefront-size macros and issues a > diagnostic if that's the case.
What's the ultimate goal here? If we're OK to warn on some obvious misuses, then it may do. However, there will be cases where we're unlikely to tell whether the use of the macro is a problem or not. E.g. it could be used in an arbitrary long chain of constexpr functions and or template instantiations that we're unlikely to see through. One way to give users a sensibly safe way to get wavefront info may look roughly like this: * `__AMDGCN_WAVEFRONT_SIZE__`, depending on the compilation options would provide different implementations: - current one -- 64 on the host, GPU-specific on the device. - checked one. GPU-specific on the device, but on the host it would provide the value matching GPU-side if all targeted GPUs agree, or something that would provide diagnostics on use (constexpr function w/ deprecated attribute?). * provide another macro `__AMDGCN_WAVEFRONT_SIZE_IS_64_ON_THE_HOST__` which will match the default current behavior unconditionally. If we want to find problems in the user's code, flip the knob to use the checked macro variant, compile user code, and find potentially problematic places. If some of them are OK to use with the host-has-wavefront-64, replace them with the macro that clearly indicates that. Eventually flip the flag to be on by default, which would prevent future misuse of the `__AMDGCN_WAVEFRONT_SIZE__` on the host. https://github.com/llvm/llvm-project/pull/109663 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
