-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proclaim pair and tuple trivially relocatable #2010
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -39,6 +39,8 @@ | |
# pragma system_header | ||
#endif // no system header | ||
|
||
#include <thrust/type_traits/is_trivially_relocatable.h> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am of the opinion that we should be moving this trait into libcu++ and derive it from But that may be something for another day. Note that the definition from the paper is much more complex and would require compiler support There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree. I also check for this trait inside CUB. I don't mind how it's called and whether it is really about |
||
|
||
#include <cuda/std/tuple> | ||
#include <cuda/std/type_traits> | ||
#include <cuda/std/utility> | ||
|
@@ -232,6 +234,10 @@ inline _CCCL_HOST_DEVICE tuple<Ts&...> tie(Ts&... ts) noexcept | |
|
||
using _CUDA_VSTD::get; | ||
|
||
template <typename... Ts> | ||
struct proclaim_trivially_relocatable<tuple<Ts...>> : ::cuda::std::conjunction<is_trivially_relocatable<Ts>...> | ||
{}; | ||
|
||
/*! \endcond | ||
*/ | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be guarded by availability of
__int128_t
We have slightly different definitions for those in cub and libcu++. Choose wisely ;)
Those are
_LIBCUDACXX_HAS_NO_INT128
andCUB_IS_INT128_ENABLED
If you want to go above and beyond we might want a_CCCL_HAS_INT128
that is globally availableThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I take libcu++.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would I want to have a
_CCCL_HAS_INT128
, if everything depends on libcu++ anyway? I would just accumulate all configuration there.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reasone is
a) libcu++ has the double negation from libc++ which is bad
b) we want to move global macro definitions into cccl because they have nothing to do with libcu++. compilers and standard modes are example of such macros. Availability of int128 definitely is one too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is news to me, I thought libcu++ was at the root of food chain.
Anyhow, I don't intend to fix this within this PR. Here is an issue: #2067