[FEA]: type-erased RAII container with specified alignment

[wence-]

Is this a duplicate?

• I confirmed there appear to be no duplicate issues for this request and that I agree to the Code of Conduct

Area

CUDA Experimental (cudax)

Is your feature request related to a problem? Please describe.

The new cuda::async_buffer and cuda::uninitialized_async_buffer are nice vocab types for stream-ordered RAII allocations of typed data. These are then naturally allocated aligned to the required alignment of their stored type.

However, if I want to store untyped data with some specified alignment I must currently roll my own buffer.

Rationale for this is where I want to do implementation hiding of some internal data structure. Perhaps because my impl type is defined in a .cuh/.cu TU that must be compiled with nvcc, but I want to interact with .cpp TUs (compiled with a host compiler) without exposing the internal type. If I have an aligned buffer then I can pass around an appropriately aligned buffer to the outside world without exposing the type.

Why not just use a generic exported type of the appropriate alignment that can be exposed?

I think that is not allowed because it would violate strict aliasing. That is, suppose my internal type is:

struct alignas(256) impl {
   ...
};

and I expose some other type in the interface

struct alignas(256) interface {
    ...
};

Then if I have an async_buffer<interface>, I don't think I can pass the interface * pointer to a function accepting an impl * pointer.

Describe the solution you'd like

I am not sure if I want the alignment specification to be part of the type:

template<std::size_t Alignment>
struct aligned_buffer {

private:
  void *data_;
  std::size_t size_;
};

// or
struct aligned_buffer {
private:
  void *data;
  std::size_t size_;
  std::size_t alignment_;
}

The advantage to the former is that APIs accepting our objects can __builtin_assume_aligned(...) to help the compiler in a type-safe way.

Describe alternatives you've considered

I implement my own buffer type.

Additional context

No response