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

[Roger Ferrer Ibanez via Phabricator via Openmp-commits]

rogfer01 added a comment.

> 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);

Just to confirm: that `local_addr` would be somehow linked to the task, I imagine it'd be initialized to something like `task->shareds + offset_to_firstprivates`, wouldn't it?

Also, perhaps you already considered if it makes sense to just have a copy function generated by the front-end rather than one of for each "firstprivatized variable that can't just be memcpy'ed"?

Also I'm curious why are you moving away (perhaps I did get this wrong!) from the current model of

1. `kmpc_omp_task_alloc`
2. capture environment
3. queue the task `kmpc_omp_task`or (if the task is `if(0)`) do an "immediate" execution but use the environment captured in 2

to something that looks like

1. (partially?) capture the environment. I think I didn't understand what `void *shared_and_private_vars` will do here. Is this something that the front-end precaptured for us?
2. copy the environment you obtained from `shared_and_private_vars` to a task-local storage and then queue the task or (if the task is `if(0)`) do an immediate execution using the environment you got from the argument to `kmpc_task`

I guess there is a benefit in the new approach. So far I read this as improving the `if(0)` case (but I may be missing something here).

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71989