================
@@ -287,6 +287,46 @@ Example Usage
basePtr->virtualFunction(); // Allowed since obj is constructed in
device code
}
+C++17 Class Template Argument Deduction (CTAD) Support
+======================================================
+
+Clang supports C++17 Class Template Argument Deduction (CTAD) in both host and
device code for HIP.
+This allows you to omit template arguments when creating class template
instances, letting the compiler
+deduce them from constructor arguments.
+
+.. code-block:: c++
+
+ #include <tuple>
+
+ __host__ __device__ void func() {
+ std::tuple<int, int> t = std::tuple(1, 1);
+ }
+
+In the above example, ``std::tuple(1, 1)`` automatically deduces the type to
be ``std::tuple<int, int>``.
+
+Deduction Guides
+----------------
+
+User-defined deduction guides are also supported. Since deduction guides are
not executable code and only
+participate in type deduction, they are treated as ``__host__ __device__`` by
the compiler, regardless of
+explicit target attributes. This ensures they are available for deduction in
both host and device contexts.
+
+.. code-block:: c++
+
+ template <typename T>
+ struct MyType {
+ T value;
+ MyType(T v) : value(v) {}
+ };
+
+ // User-defined deduction guide
+ template <typename T>
+ MyType(T) -> MyType<T>;
----------------
Artem-B wrote:
Fair point, but we should still consider the big picture. NVCC's current way of
handling this may have been driven by convenience more than the sound
principles. For deduction guidelines we do not have to worry much about
existing code being compilable. The fix to make code compatible with either
approach is also simple -- just remove attributes, or make them HD.
I don't have a good picture where we're going to end up with this, so I'd
rather keep our options open. It's generally easier to relax restrictions than
to tighten them. If we accept attributes, but ignore them, they will
proliferate. Then, if we want to make attribute-based guides work in the
future, the change will break existing users. On the other hand, if we start
with a strict "no H or D" requirement, allowing H or D attributes in the future
will be much easier, as it would only apply to the new code.
To think of it, I'm starting to think that H or D use should be an error, not
a warning. At least for now.
A second order issue with accepting but ignoring H/D without diagnostics is
that it makes handling H/D inconsistent. Whoever reads the code will have to be
on guard -- if they see `__device__` they would need to keep in mind that if
it's applied to a deduction guide, then it's not real. I'd rather keep target
attribute semantics unambiguous -- if the target attribute is used, it does
make a meaningful difference. While it is technically an attribute,
semantically it's closer to a language keyword. Dropping/ignoring it when it's
written by the user is not something we should do.
https://github.com/llvm/llvm-project/pull/168711
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
