-
Notifications
You must be signed in to change notification settings - Fork 757
Conversation
…ces) for variadic tuple
Changes LGTM. I'll start some testing soon, and I also want to check the impact of the new recursive templates on compile times. |
Just to make sure I follow, are you just referring to |
Those, but also others like the But I'll run some tests before we put too much work into fixing this, the overhead may be negligible in these cases. |
Gotcha. Regarding |
DVS CL 29194398. |
Good news and bad news. Good news: This doesn't significantly impact compile times. Bad news: This doesn't build cleanly on our internal CI. Can you take a look at this error?
|
Sorry, I should've tested with |
It's this commit [53a1d25] specifically. I suspect that this is an #ifdef __NVCC__
template<typename Tuple,
template<typename> class UnaryMetaFunction,
typename IndexSequence>
struct tuple_meta_transform_WAR_NVCC;
template<typename Tuple,
template<typename> class UnaryMetaFunction,
size_t... Is>
struct tuple_meta_transform_WAR_NVCC<Tuple, UnaryMetaFunction, thrust::index_sequence<Is...>>
{
typedef thrust::tuple<
typename UnaryMetaFunction<typename thrust::tuple_element<Is,Tuple>::type>::type...
> type;
};
template<typename Tuple,
template<typename> class UnaryMetaFunction>
struct tuple_meta_transform
{
typedef typename tuple_meta_transform_WAR_NVCC<Tuple, UnaryMetaFunction, thrust::make_index_sequence<thrust::tuple_size<Tuple>::value>>::type type;
};
#else
template<typename Tuple,
template<typename> class UnaryMetaFunction,
typename IndexSequence = thrust::make_index_sequence<thrust::tuple_size<Tuple>::value>>
struct tuple_meta_transform;
template<typename Tuple,
template<typename> class UnaryMetaFunction,
size_t... Is>
struct tuple_meta_transform<Tuple, UnaryMetaFunction, thrust::index_sequence<Is...>>
{
typedef thrust::tuple<
typename UnaryMetaFunction<typename thrust::tuple_element<Is,Tuple>::type>::type...
> type;
};
#endif |
What do you think the best approach would be? Guard the workaround with |
Just be sure to leave a comment near the WAR explaining why it's needed. |
I don't think a reproducer would be too difficult to construct. I reproduced the error(s) with nvcc 11.0 and gcc 9.2 (on centos7). ctest is running currently, so far so good. Would you rather me commit the fix on top of the existing commits? Or should I redo [53a1d25] as a single clean commit with the workaround included from the beginning? Also, does this look ok? // introduce an intermediate type tuple_meta_transform_WAR_NVCC
// rather than directly specializing tuple_meta_transform with
// default argument IndexSequence = thrust::make_index_sequence<thrust::tuple_size<Tuple>::value>
// to workaround nvcc 11.0 compiler bug
template<typename Tuple,
template<typename> class UnaryMetaFunction,
typename IndexSequence>
struct tuple_meta_transform_WAR_NVCC;
template<typename Tuple,
template<typename> class UnaryMetaFunction,
size_t... Is>
struct tuple_meta_transform_WAR_NVCC<Tuple, UnaryMetaFunction, thrust::index_sequence<Is...>>
{
typedef thrust::tuple<
typename UnaryMetaFunction<typename thrust::tuple_element<Is,Tuple>::type>::type...
> type;
};
template<typename Tuple,
template<typename> class UnaryMetaFunction>
struct tuple_meta_transform
{
typedef typename tuple_meta_transform_WAR_NVCC<Tuple, UnaryMetaFunction, thrust::make_index_sequence<thrust::tuple_size<Tuple>::value>>::type type;
}; |
That looks good to me. I'll see if I can locally reproduce this on gcc 9 tomorrow. Feel free to just push the fix to the top of the current branch. We'll need to squash this branch down to a single commit before integrating it due to some funky internal NVIDIA workflow restrictions, so there's no need to go back and clean up the history. |
Done. Thanks |
I tried, but couldn't isolate to a standalone reproducer. |
I pushed changes from #1311. |
DVS CL: 29265481 |
Can one of the admins verify this patch? |
ok to test |
Some simplifications preparing Thrust for a variadic tuple implementation (some day... NVIDIA/cccl#695). Other changes would require a bit more coordination and can come separately, assuming these sorts of changes are now mergeable.
With
-DTHRUST_DEVICE_SYSTEM=CPP
I get: