Re: [PATCH]: libgompd add parallel handle functions

[Mohamed Atef <mohamedatef1698@gmail.com>]

في الاثنين، ٦ يونيو، ٢٠٢٢ ٧:١٣ م Jakub Jelinek via Gcc-patches <
gcc-patches@gcc.gnu.org> كتب:

> On Mon, Jun 06, 2022 at 01:48:22AM +0200, Mohamed Sayed via Gcc-patches
> wrote:
> > This patch adds parallel region handles specified in section 5.5.3.
> > >From examining libgomp code, I found that struct gomp_team describes the
> > parallel region.
>
> I think it would be nice to first find out what the different
> ompd_{parallel,thread,task}_handle_t should actually contain.
>
> In GOMP, the first one maps to struct gomp_team, the middle one to
> struct gomp_thread and the last one to struct gomp_task.
>
> Functions that create those are:
> For ompd_thread_handle_t that is ompd_get_thread_in_parallel and
> ompd_get_thread_handle.
> For ompd_parallel_handle_t that is ompd_get_curr_parallel_handle,
> ompd_get_enclosing_parallel_handle and ompd_get_task_parallel_handle.
> For ompd_task_handle_t that is ompd_get_curr_task_handle,
> ompd_get_generating_task_handle, ompd_get_scheduling_task_handle and
> ompd_get_task_in_parallel.
>
> What those handles point to is something libgompd allocates using
> the allocator callback and it is up to the library what it puts there,
> typically it should contain the address of those corresponding
> gomp structures and whatever else is needed (say address space handle
> or some contexts).
>
> > The Thread handle gives the address of gomp_thread so, I tried to
> > access *team
> > gomp_thread->ts->team.
>
> Actually gomp_thread's ts.team (ts is not a pointer, but a nested struct).
>
I think the implementation is correct But there's a typo in the comment.

>
> > The parallel handle is the team pointer in team state.
> > I have a question about ompd_get_task_parallel_handle
> > https://www.openmp.org/spec-html/5.0/openmpsu218.html
> > How can i reach gomp_team from gomp_taske
> > And the union in gomp_task has two entries gomp_sem_t and gomp_team
>
> So, for the 4 functions you want to implement:
> ompd_get_curr_parallel_handle when you'll have struct gomp_thread *
> and want struct gomp_team * you load thr->ts.team.
> Note, the implicit parallel is usually represented by NULL in thr->ts.team,
> that case then means it has just a single thread etc.
>
> ompd_get_enclosing_parallel_handle when you'll have struct gomp_team *
> and want the enclosing team.  team->prev_ts.team is what you are after,
> if it is non-NULL, it is the enclosing parallel, if it is NULL, I think
> one should verify e.g. host teams construct in that case, but
> otherwise it is the implicit parallel that one probably needs to represent
> somehow too.
>
So for both cases one should read the value of *team and if it's NULL, the
function returns some error state (eg. ompd_rc_unavailable)

>
> ompd_get_task_parallel_handle when you'll have struct gomp_task *
> and want the struct gomp_team it is in.
> I'm afraid the library doesn't track this, it doesn't need it for anything.
> One possibility to resolve this is perhaps if all functions that
> allocate ompd_task_handle_t can't know the corresponding struct gomp_thread
> too, then you could store in the private structure or ompd_task_handle_t
> both struct gomp_task * and struct gomp_thread *.
>
I will ask the guys to try this if it's impossible then we delay this
function.

> If that is impossible, we could add such a pointer, but it would increase
> both memory and runtime overhead of the library.
>
>         Jakub
>
>