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

Roger Ferrer Ibanez via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Tue Jan 14 11:32:44 PST 2020

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


  rG LLVM Github Monorepo



More information about the Openmp-commits mailing list