[clang] Add __has_target_feature

[yaxunl]

Summary

Depending on whether a target feature is enabled or not,
programs may choose different algorithm or different
builtin functions to use.

Instead of let each target to emit predefined macros
for specific target feature, this patch introduce a
function-like builtin macro __has_target_feature.

[yaxunl]

fix typo

[tra]

clang/docs/LanguageExtensions.rst

275

Do you have a better example? This particular case could've been handled by existing __has_builtin().

While I could see usefulness of checking features (e.g. for CUDA/NVPTX it could be used to chose inline assembly supported only by newer PTX versions, but even then that choice could be made using existing methods, even if they are not always direct (e.g. by using CUDA_VERSION as a proxy for "new enough PTX version").

[yaxunl]

clang/docs/LanguageExtensions.rst

275

__has_builtin returns 1 as long as the builtin is known to clang, even if the builtin is not supported by the target CPU. This is because the required target feature for a builtin is in ASTContext, whereas __has_builtin is evaluated in preprocessor, where the information is not known.

[aaron.ballman]

It's not clear to me why existing facilities shouldn't be extended to cover this case rather than coming up with another feature testing macro. There's already plenty of confusion for users to decide between __has_feature and __has_extension, and now we're talking about adding a third choice to the mix.

clang/docs/LanguageExtensions.rst

260

The first question that comes to mind for me is: why is __has_feature not sufficient?

275

__has_builtin returns 1 as long as the builtin is known to clang, even if the builtin is not supported by the target CPU. This is because the required target feature for a builtin is in ASTContext, whereas __has_builtin is evaluated in preprocessor, where the information is not known.

Why is that not a deficiency with __has_builtin that we should fix?

[yaxunl]

clang/docs/LanguageExtensions.rst

260

__has_target_feature accepts predefined target features for the specified target triple and CPU. The names of target features are determined by the target. They may overlap with clang features and cause ambiguity. Another issue is that they usually contain '-', which makes them not valid identifiers of C/C++, therefore the builtin macro has to accept a string literal argument instead of identifier argument like __has_feature.

275

It is arguable whether this is a bug for __has_builtin. I tend to treat it as a bug and think it should be fixed. However, fixing it may cause regressions since there may be existing code expecting __has_builtin not depending on availability of required target feature. This will limit the usability of a fix for this issue.

Even if we agree that this is a bug for __has_builtin which should be fixed, this does conflict with adding __has_target_feature, as __has_target_feature has more uses than determining whether a target builtin is available, e.g. choosing different algorithms based on availability of certain target feature, or using certain inline assembly code.

[yaxunl]

clang/docs/LanguageExtensions.rst

275

It is arguable whether this is a bug for __has_builtin. I tend to treat it as a bug and think it should be fixed. However, fixing it may cause regressions since there may be existing code expecting __has_builtin not depending on availability of required target feature. This will limit the usability of a fix for this issue.

Even if we agree that this is a bug for __has_builtin which should be fixed, this does conflict with adding __has_target_feature, as __has_target_feature has more uses than determining whether a target builtin is available, e.g. choosing different algorithms based on availability of certain target feature, or using certain inline assembly code.

sorry typo. this does not conflict

[tra]

Oops. forgot to hit 'submit' last week, so there's some overlap with Aaron's question.

clang/docs/LanguageExtensions.rst

275

I'm missing something. __has_target_feature("s-memtime-inst") is also evaluated by preprocessor, right next to where __has_target_builtin is processed.
I guess what you're saying is that preprocessor does not pay attention to the target feature conditions attached to those builtins.
Those are evaluted in CodeGenFunction::checkTargetFeatures.

This means that in order to use __has_feature() to detect availability of target builtins would effectively require the user to specify exactly the same set of conditions, as applied to the builtin. That will work for builtins that map to features 1:1, but it will be prone to breaking for NVPTX builtins that carry fairly large set of feature requirements and that set changes every time we add a new PTX or GPU variant, which happens fairly often.

I wonder if it may be better to generalize target builtin feature evaluation and use it from both preprocessor and the codegen and just stick with __has_builtin, only now working correctly to indicate availability of the target builtins.

[yaxunl]

clang/docs/LanguageExtensions.rst

275

Opened https://reviews.llvm.org/D125829 to fix __has_builtin

[aaron.ballman]

clang/docs/LanguageExtensions.rst

260

Do we have to use a string literal? I am presuming there's an enumerated list of features for each target, and thus we can use an identifier argument (it might turn around and map that identifier back to a string literal, but that's fine). But I'm not certain I understand how a target feature will overlap with a clang feature and cause ambiguity.

My concerns really boil down to:

• It's already hard enough for users to know when to use __has_extension vs __has_feature and this is adding another option into the mix.
• There's no documentation about what constitutes a valid string literal for this feature and I don't know how a user would go about discovering the full enumerated list for any given target. Also, are these strings guaranteed to be stable (spelling doesn't change, strings aren't removed, etc)?
• (much smaller concern) A string literal may not be the most user-friendly way to surface the functionality (tools typically don't auto-complete string literals or do typo correction within them).

clang/docs/LanguageExtensions.rst

#ifdef __is_identifier          // Compatibility with non-clang compilers.
     #if __is_identifier(__wchar_t)
       typedef wchar_t __wchar_t;
     #endif
   #endif
 
   __wchar_t WideCharacter;
   ...
 
+``__has_target_feature``
+------------------------
+
+This function-like macro takes a single string literal argument that is the name of
+a target feature. It evaluates to 1 if the target feature is enabled or 0 if not.
+It can be used like this:
+
+.. code-block:: c++
+
+  #ifndef __has_target_feature         // Optional of course.
+    #define __has_target_feature(x) 0  // Compatibility with non-clang compilers.
+  #endif
+
+  ...
+  // On amdgcn target
+  #if __has_target_feature("s-memtime-inst")
+    x = __builtin_amdgcn_s_memtime();
+  #else
+    x = __builtin_readcyclecounter();
+  #endif
+  ...
+
 Include File Checking Macros
 ============================
 
 Not all developments systems have the same include files.  The
 :ref:`langext-__has_include` and :ref:`langext-__has_include_next` macros allow
 you to check for the existence of an include file before doing a possibly
 failing ``#include`` directive.  Include file checking macros must be used
 as expressions in ``#if`` or ``#elif`` preprocessing directives.

clang/docs/ReleaseNotes.rst

- Clang now supports randomizing structure layout in C. This feature is a
   A seed value is required to enable randomization, and is deterministic based
   on a seed value. Use the ``-frandomize-layout-seed=`` or
   ``-frandomize-layout-seed-file=`` flags.
 
   .. note::
 
       Randomizing structure layout is a C-only feature.
 
+- Clang now supports function-like macro __has_target_feature which returns 1
+  if the specified target feature is enabled.
+
 Bug Fixes
 ------------------
 - ``CXXNewExpr::getArraySize()`` previously returned a ``llvm::Optional``
   wrapping a ``nullptr`` when the ``CXXNewExpr`` did not have an array
   size expression. This was fixed and ``::getArraySize()`` will now always
   either return ``None`` or a ``llvm::Optional`` wrapping a valid ``Expr*``.
   This fixes `Issue 53742 <https://github.com/llvm/llvm-project/issues/53742>`_.
 - We now ignore full expressions when traversing cast subexpressions. This

clang/include/clang/Lex/Preprocessor.h

class Preprocessor {
   IdentifierInfo *Ident__COUNTER__;                // __COUNTER__
   IdentifierInfo *Ident_Pragma, *Ident__pragma;    // _Pragma, __pragma
   IdentifierInfo *Ident__identifier;               // __identifier
   IdentifierInfo *Ident__VA_ARGS__;                // __VA_ARGS__
   IdentifierInfo *Ident__VA_OPT__;                 // __VA_OPT__
   IdentifierInfo *Ident__has_feature;              // __has_feature
   IdentifierInfo *Ident__has_extension;            // __has_extension
   IdentifierInfo *Ident__has_builtin;              // __has_builtin
+  IdentifierInfo *Ident__has_target_feature;       // __has_target_feature
   IdentifierInfo *Ident__has_attribute;            // __has_attribute
   IdentifierInfo *Ident__has_include;              // __has_include
   IdentifierInfo *Ident__has_include_next;         // __has_include_next
   IdentifierInfo *Ident__has_warning;              // __has_warning
   IdentifierInfo *Ident__is_identifier;            // __is_identifier
   IdentifierInfo *Ident__building_module;          // __building_module
   IdentifierInfo *Ident__MODULE__;                 // __MODULE__
   IdentifierInfo *Ident__has_cpp_attribute;        // __has_cpp_attribute

clang/lib/Lex/PPMacroExpansion.cpp

void Preprocessor::RegisterBuiltinMacros() {
   }
 
   // Clang Extensions.
   Ident__FILE_NAME__      = RegisterBuiltinMacro(*this, "__FILE_NAME__");
   Ident__has_feature      = RegisterBuiltinMacro(*this, "__has_feature");
   Ident__has_extension    = RegisterBuiltinMacro(*this, "__has_extension");
   Ident__has_builtin      = RegisterBuiltinMacro(*this, "__has_builtin");
   Ident__has_attribute    = RegisterBuiltinMacro(*this, "__has_attribute");
+  Ident__has_target_feature =
+      RegisterBuiltinMacro(*this, "__has_target_feature");
   if (!getLangOpts().CPlusPlus)
     Ident__has_c_attribute = RegisterBuiltinMacro(*this, "__has_c_attribute");
   else
     Ident__has_c_attribute = nullptr;
 
   Ident__has_declspec = RegisterBuiltinMacro(*this, "__has_declspec_attribute");
   Ident__has_include      = RegisterBuiltinMacro(*this, "__has_include");
   Ident__has_include_next = RegisterBuiltinMacro(*this, "__has_include_next");
if (II == Ident__LINE__) {
     Tok.setKind(tok::numeric_constant);
   } else if (II == Ident__has_feature) {
     EvaluateFeatureLikeBuiltinMacro(OS, Tok, II, *this, false,
       [this](Token &Tok, bool &HasLexedNextToken) -> int {
         IdentifierInfo *II = ExpectFeatureIdentifierInfo(Tok, *this,
                                            diag::err_feature_check_malformed);
         return II && HasFeature(*this, II->getName());
       });
+  } else if (II == Ident__has_target_feature) {
+    EvaluateFeatureLikeBuiltinMacro(
+        OS, Tok, II, *this, false,
+        [this](Token &Tok, bool &HasLexedNextToken) -> int {
+          std::string TargetFeatureName;
+          HasLexedNextToken = Tok.is(tok::string_literal);
+          if (!FinishLexStringLiteral(Tok, TargetFeatureName,
+                                      "'__has_target_feature'",
+                                      /*AllowMacroExpansion=*/false))
+            return false;
+          auto FeatureMap = getTargetInfo().getTargetOpts().FeatureMap;
+          auto Loc = FeatureMap.find(TargetFeatureName);
+          return Loc != FeatureMap.end() && Loc->second;
+        });
   } else if (II == Ident__has_extension) {
     EvaluateFeatureLikeBuiltinMacro(OS, Tok, II, *this, false,
       [this](Token &Tok, bool &HasLexedNextToken) -> int {
         IdentifierInfo *II = ExpectFeatureIdentifierInfo(Tok, *this,
                                            diag::err_feature_check_malformed);
         return II && HasExtension(*this, II->getName());
       });
   } else if (II == Ident__has_builtin) {

clang/test/Lexer/has_target_feature.cpp

+// RUN: %clang_cc1 -triple amdgcn -target-cpu gfx906 -E %s -o - | FileCheck %s
+
+// CHECK: has_s_memtime_inst
+#if __has_target_feature("s-memtime-inst")
+  int has_s_memtime_inst;
+#endif
+
+// CHECK-NOT: has_gfx10_inst
+#if __has_target_feature("gfx10-inst")
+  int has_gfx10_inst;
+#endif