Re: [PATCH]: libgompd add parallel handle functions

[Jakub Jelinek <jakub@redhat.com>]

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

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

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 *.
If that is impossible, we could add such a pointer, but it would increase
both memory and runtime overhead of the library.

	Jakub