[Openmp-commits] [PATCH] D100181: [OpenMP] [OMPD] [1/6] Implementation of OMPD debugging library - libompd. Code changes in openmp/runtime to support libompd.

[Joachim Protze via Phabricator via Openmp-commits]

protze.joachim added inline comments.


================
Comment at: openmp/runtime/src/kmp_runtime.cpp:1343
         OMPT_GET_FRAME_ADDRESS(0);
+#if OMPD_SUPPORT
+    OMPT_CUR_TASK_INFO(this_thr)->scheduling_parent =
----------------
hbae wrote:
> Why do we need scheduling task for implicit tasks while we don't call it task scheduling in the specification?
I think, the specification of `ompd_get_scheduling_task_handle` and `ompd_get_generating_task_handle` needs some refinement.

I think, the background here is the following:
> On return, the scheduling_task_handle argument points to a location that points to a handle for the
> task that is still on the stack of execution on the same thread and was deferred in favor of executing
> the selected task.

When reaching a taskwait, the execution of the encountering implicit task is deferred to execute some explicit tasks.
Similarly, for a parallel region, the execution of the encountering implicit task is deferred to execute the implicit task of the parallel region.

When thinking about possible debugger workflow, it might help to cut the chain as you suggest and implicitly tell the debugger, that the implicit task is reached and the debugger should use `ompd_get_generating_task_handle` to get the parent task on the stack.

For the function `ompd_get_generating_task_handle`, the following might be an issue:
> The `ompd_get_generating_task_handle` function obtains a pointer to the task handle for the task that encountered the OpenMP task construct that generated the task represented by task_handle.

Since the parallel construct is no task construct, following this definition, the task encountering a parallel construct is also not the generating task. The glossary entry for //generating task// also refers to the parallel region and not the implicit task.

I think, we should clarify the terms in the next tools subcommittee call.


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

https://reviews.llvm.org/D100181