[Openmp-commits] [PATCH] D71989: [OpenMP][IRBuilder][WIP] Prototype `omp task` support

[Johannes Doerfert via Phabricator via Openmp-commits]

jdoerfert added a comment.

In D71989#1819219 <https://reviews.llvm.org/D71989#1819219>, @AndreyChurbanov wrote:

> > the task create and task issue step are
> >  conceptually not separated anymore as it is
>
> I don't think this can work reliably.  Because not all C++ objects can be mem-copied.
>  E.g. an object can keep its own address or reference, and mem-copy will make it broken.
>  This could be fixed by generating (optional) thunk routine which would create all needed objects 
>  in the library-allocated space, and similar routine which would destroy all the created objects.


I agree. `memcpy` will only work for certain types (incl. all PoD types). We need to extend this later to pass the copy constructor function pointers and locations of the original object.
We should keep `kmp_uint32 sizeof_shared_and_private_vars, void *shared_and_private_vars` for the simple cases and add something like:

  /// Copy wrapper takes the address of an object and the address the copy is going to be initialized in and returns the address right after the new object. 
  typedef void*(*copy_wrapper)(void * /* src_addr */, void * /* trg_addr */);
   
  __kmpc_task( ..., kmp_uint32 sizeof_copy_infos, copy_wrapper * copy_wrapper_list, void * copied_obj_list, ...)

and we then call the copy constructors like this:

  void *local_addr = ...;
  for (kmp_uint32 u = 0; u < sizeof_copy_infos; ++u)
    local_addr = copy_wrapper_list[u](copied_obj_list[u], local_addr);

@rogfer01 @AndreyChurbanov What do you think? (I can do this in this patch or later)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71989/new/

https://reviews.llvm.org/D71989