Skip to content

cuda::is_trivially_copyable#8265

Open
fbusato wants to merge 39 commits intoNVIDIA:mainfrom
fbusato:relaxed-type-traits
Open

cuda::is_trivially_copyable#8265
fbusato wants to merge 39 commits intoNVIDIA:mainfrom
fbusato:relaxed-type-traits

Conversation

@fbusato
Copy link
Copy Markdown
Contributor

@fbusato fbusato commented Apr 1, 2026

Description

Followup of the discussion in

The PR introduces cuda::is_trivially_copyable_relaxed to support types that are actually trivially copyable but not recognized by the C++ std::is_trivially_copyable type trait.

The new trait supports:

  • trivially copyable types.
  • extended floating-point types.
  • extended floating-point vector types.
  • Raw arrays, cuda::std::array.
  • cuda::std::pair.
  • cuda::std::tuple.
  • Nested compositions of the above cases.

Potentially affected paths by std::is_trivially_copyable

unsupported cases:

  • cuda/std/__atomic/types/base.h:39
  • cuda/std/__atomic/types/reference.h:39
  • cuda/__memcpy_async/memcpy_async_barrier.h:61
  • cuda/__memcpy_async/memcpy_async_tx.h:58
  • cuda/__container/buffer.h:111
  • cuda/__algorithm/copy.h:73
  • cuda/__algorithm/fill.h:42
  • cuda/std/string_view:147

fallback to slower path:

  • cuda/std/__algorithm/copy.h:102
  • cuda/std/__algorithm/copy_backward.h:50
  • cuda/std/__algorithm/move.h:54
  • cuda/std/__algorithm/move_backward.h:53
  • cuda/std/__bit/bit_cast.h:55
  • cub/device/dispatch/kernels/kernel_histogram.cuh:81
  • cub/detail/uninitialized_copy.cuh:33
  • thrust/type_traits/is_trivially_relocatable.h:213
  • cudax/include/cuda/experimental/__kernel/kernel_ref.cuh:54

Require #8347

@fbusato fbusato self-assigned this Apr 1, 2026
@fbusato fbusato added this to CCCL Apr 1, 2026
@fbusato fbusato added the libcu++ For all items related to libcu++ label Apr 1, 2026
@fbusato fbusato requested a review from a team as a code owner April 1, 2026 19:51
@github-project-automation github-project-automation bot moved this to Todo in CCCL Apr 1, 2026
@fbusato fbusato requested a review from wmaxey April 1, 2026 19:51
@cccl-authenticator-app cccl-authenticator-app bot moved this from Todo to In Review in CCCL Apr 1, 2026
@fbusato fbusato requested a review from a team as a code owner April 1, 2026 19:55
@fbusato fbusato requested a review from gonidelis April 1, 2026 19:55
Copy link
Copy Markdown
Contributor

@miscco miscco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not too excited about this.

We need to be really careful here because the compiler may also break in some of those cases.

I did some experiments in #3183

@github-project-automation github-project-automation bot moved this from In Review to In Progress in CCCL Apr 1, 2026
@bernhardmgruber
Copy link
Copy Markdown
Contributor

I wanted to start a discussion for some time to add such a trait, but I would really keep this feature internally for now until it is sufficiently baked. I would really like this feature to make thrust::is_trivially_relocatable and THRUST_PROCLAIM_TRIVIALLY_RELOCATABLE obsolete, because those two are often used wrongly, so we should make sure the new trait here can replace it.

Copy link
Copy Markdown
Contributor

@davebayer davebayer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not a fan of this trait. We bend C++ rules to fix poorly designed nvfp types. We would have to basically change every use of is_trivially_copyable and is_trivially_copy_constructible to this trait to make it work consistently in libcu++.

I don't think this is a good idea, we should rather insist of the nvfp types being fixed.

Comment on lines +40 to +41
Users may specialize ``cuda::is_trivially_copyable_relaxed`` for their own types whose memory representation is safe to copy
with ``memcpy`` but that the compiler does not consider trivially copyable.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this just UB?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not for the types that we care about. Said that, the user could provide an object that triggers UB. I can highlight this point in the documentation but we cannot do anything to explicitly prevent it.

@fbusato
Copy link
Copy Markdown
Contributor Author

fbusato commented Apr 1, 2026

We need to be really careful here because the compiler may also break in some of those cases.

I did some experiments in #3183

Integrated and extended the tests that you point out. Everything works

@fbusato
Copy link
Copy Markdown
Contributor Author

fbusato commented Apr 1, 2026

I wanted to start a discussion for some time to add such a trait, but I would really keep this feature internally for now until it is sufficiently baked. I would really like this feature to make thrust::is_trivially_relocatable and THRUST_PROCLAIM_TRIVIALLY_RELOCATABLE obsolete, because those two are often used wrongly, so we should make sure the new trait here can replace it.

the actual issue is that the user can extend the trait to custom types. It needs to be public

@fbusato
Copy link
Copy Markdown
Contributor Author

fbusato commented Apr 1, 2026

I am not a fan of this trait. We bend C++ rules to fix poorly designed nvfp types. We would have to basically change every use of is_trivially_copyable and is_trivially_copy_constructible to this trait to make it work consistently in libcu++.
I don't think this is a good idea, we should rather insist of the nvfp types being fixed.

there are no plan for that. nvfp types are not trivially copyable for optimization purposes.

@jrhemstad
Copy link
Copy Markdown
Collaborator

we should rather insist of the nvfp types being fixed.

This isn't going to happen and we shouldn't delude ourselves into thinking it ever will.

@fbusato fbusato moved this from In Progress to In Review in CCCL Apr 1, 2026
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move this out of the PR.

This is a nontrivial piece of code and the current implementation seems really costly.

I want this in a separate PR so that we can properly review it

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine, I based the implementation on the code from stdexec. Eric already review it

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not against merging it, but I want it in a separate PR

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

created a new PR #8347

#if defined(_CCCL_BUILTIN_BIT_CAST)
return _CCCL_BUILTIN_BIT_CAST(_To, __from);
#else // ^^^ _CCCL_BUILTIN_BIT_CAST ^^^ / vvv !_CCCL_BUILTIN_BIT_CAST vvv
static_assert(is_trivially_default_constructible_v<_To>,
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

C++ specification does not impose this constrain https://eel.is/c++draft/bit.cast. is_trivially_default_constructible_v is too strict. cuda::std::complex fails for example.

We only need to check if _To __temp; compiles. The best match is C++20 std::default_initializable

@fbusato fbusato requested a review from a team as a code owner April 9, 2026 18:31
@github-actions

This comment has been minimized.

fbusato added 2 commits April 9, 2026 12:44
…elaxed-type-traits

# Conflicts:
#	libcudacxx/include/cuda/std/__cccl/builtin.h
@github-actions

This comment has been minimized.

@fbusato fbusato requested a review from a team as a code owner April 9, 2026 21:50
@github-actions

This comment has been minimized.

@miscco
Copy link
Copy Markdown
Contributor

miscco commented Apr 10, 2026

@fbusato I checked the standard and it turns out that C++23 made complex trivially copyable for standard floating point types, so we should only specialize for __half and __nv_bfloat16

See #8356

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions
Copy link
Copy Markdown
Contributor

😬 CI Workflow Results

🟥 Finished in 3h 41m: Pass: 92%/162 | Total: 8d 13h | Max: 3h 41m | Hits: 38%/392424

See results here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

libcu++ For all items related to libcu++

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

6 participants