================ @@ -96,6 +100,47 @@ the ``<cmath>`` header file to conditionally make a function constexpr whenever the constant evaluation of the corresponding builtin (for example, ``std::fmax`` calls ``__builtin_fmax``) is supported in Clang. +``__has_target_builtin`` +------------------------ + +This function-like macro takes a single identifier argument that is the name of +a builtin function, a builtin pseudo-function (taking one or more type +arguments), or a builtin template. +It evaluates to 1 if the builtin is supported on the current target or 0 if not. + +``__has_builtin`` and ``__has_target_builtin`` behave identically for normal C++ compilations. + +For heterogeneous compilations that see source code intended for more than one target: + +``__has_builtin`` returns true if the builtin is known to the compiler +(i.e. it's available via one of the targets), but makes no promises whether it's available on the current target. +The compiler can parse it, but not necessarily generate code for it. + +``__has_target_builtin`` returns true if the builtin can actually be generated for the current target. + +It can be used like this: + +.. code-block:: c++ + + #ifdef __CUDA__ + #if __has_target_builtin(__builtin_trap) + __builtin_trap(); + #else + abort(); + #endif + #else // !CUDA + #if __has_builtin(__builtin_trap) + __builtin_trap(); + #else + abort(); + #endif ---------------- sarnex wrote:
thanks, its not necessary, but i was thinking we leave it to suggest users to only use this for offloading, even if it does work for normal compilation modes. if you think the explanation of the differences between `has_builtin` and `has_target_builtin` is enough for users, i remove the offload/nooffload check from the example https://github.com/llvm/llvm-project/pull/126324 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
