================ @@ -96,6 +101,37 @@ 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. +The behavior is different than ``__has_builtin`` when there is an auxiliary target, +such when offloading to a target device. +It can be used like this: + +.. code-block:: c++ + + #ifndef __has_target_builtin // Optional of course. + #define __has_target_builtin(x) 0 // Compatibility with non-clang compilers. + #endif ---------------- Artem-B wrote:
We have somewhat conflicting requirements: * On C++ side, writers do not care about offloading (and we can't force them to). They only have `__has_builtin()` and it does what they need -- if the given builtin exists it will be compileable. * On offloading side, we want C++ headers to work out of the box for the host side. Ideally with the host and device compilations seeing the same code after preprocessing, and that's where we get into this problem. We can't tell whether the original C++ code needs `__has_builtin()` (works well enough for most uses *inside* of host function bodies) or if it needs `__has_target_builtin()` (e.g. when it's used inside a lambda or constexpr function which is implicitly HD, and we do need to generate code for it). I'm not sure we can find a universal solution. That said, `__has_target_builtin()` gives us some flexibility on the offloading side. C++ side should stick with `__has_builtin()`. `__has_target_builtin()` should only be used when offloading comes into the picture, *but* it includes the possibility that it will be used in the headers shared with C++ and therefore the builtin itself should be available there. 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
