[PATCH] D154133: [amdgpu] start documenting amdgpu support by clang
Siu Chi Chan via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Jul 7 11:35:17 PDT 2023
scchan added inline comments.
================
Comment at: clang/docs/AMDGPUSupport.rst:47
+ * - ``__amdgcn_feature_<feature-name>__``
+ - Defined for each supported target feature. The value is 1 if the feature is enabled and 0 if it is disabled. Allowed feature names are sramecc and xnack.
+ * - ``__AMDGCN_CUMODE__``
----------------
yaxunl wrote:
> scchan wrote:
> > This set of feature macros is tricky. A feature macro is defined only when the corresponding target feature has been explicitly specified during compilation; otherwise it's undefined. Users will have to refer to the target feature table to get the semantic of each state. For example, for xnack, undefined=="any", 1 for xnack+, 0 for xnack-.
> >
> > Is there a reason we don't support features other than sramecc and xnack?
> This macro is designed to support Target ID only, therefore it is only emitted when target ID containing the feature is used.
>
> The target ID features are stable since they are used to select code objects from fat binaries.
>
> My understanding is that other features used by amdgpu backend do not have stable feature names, therefore are not suitable to be used as predefined macros for users to condition their code.
The current wording seems to imply that a feature macro is always defined if that target feature is supported but that's not the case. For example, the macro __amdgcn_feature_xnack__ is undefined if a user compiles for xnack="any".
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154133/new/
https://reviews.llvm.org/D154133
More information about the cfe-commits
mailing list