The attached patch adds support for ompt_event_task_dependences and
ompt_event_task_dependence_pair events from the OMPT specification [1]. These
events only apply to OpenMP 4.0 and 4.1 (aka 4.5) because task dependencies
were introduced in 4.0.
With respect to the changes:
ompt_event_task_dependences
According to the specification, this event is raised after the task has been
created, thefore this event needs to be raised after ompt_event_task_begin
(in __kmp_task_start). However, the dependencies are known at
__kmpc_omp_task_with_deps which occurs before __kmp_task_start. My modifications
extend the ompt_task_info_t struct in order to store the dependencies of the
task when _kmpc_omp_task_with_deps occurs and then they are emitted in
__kmp_task_start just after raising the ompt_event_task_begin. The deps field
is allocated and valid until the event is raised and it is freed and set
to null afterwards.
ompt_event_task_dependence_pair
The processing of the dependences (i.e. checking whenever a dependence is
already satisfied) is done within __kmp_process_deps. That function checks
every dependence and calls the __kmp_track_dependence routine which gives some
support for graphical output. I used that routine to emit the dependence pair
but I also needed to know the sink_task. Despite the fact that the code within
KMP_SUPPORT_GRAPH_OUTPUT refers to task_sink it may be null because
sink->dn.task (there's a comment regarding this) and in fact it does not point
to a proper pointer value because the value is set in node->dn.task = task;
after the __kmp_process_deps calls in __kmp_check_deps. I have extended the
__kmp_process_deps and __kmp_track_dependence parameter list to receive the
sink_task.
[1] https://github.com/OpenMPToolsInterface/OMPT-Technical-Report/blob/target/ompt-tr.pdf
Patch by Harald Servat
Differential Revision: http://reviews.llvm.org/D14746
llvm-svn: 259038
Prior to this change, OMPT had a status flag ompt_status, which could take
several values. This was due to an earlier OMPT design that had several levels
of enablement (ready, disabled, tracking state, tracking callbacks). The
current OMPT design has OMPT support either on or off.
This revision replaces ompt_status with a boolean flag ompt_enabled, which
simplifies the runtime logic for OMPT.
Patch by John Mellor-Crummey
Differential Revision: http://reviews.llvm.org/D12999
llvm-svn: 248189
The OMPT specification has changed. This revision brings the LLVM OpenMP
implementation up to date.
Technical overview of changes:
Previously, a public weak symbol ompt_initialize was called after the OpenMP
runtime is initialized. The new interface calls a global weak symbol ompt_tool
prior to initialization. If a tool is present, ompt_tool returns a pointer to
a function that matches the signature for ompt_initialize. After OpenMP is
initialized the function pointer is called to initialize a tool.
Knowing that OMPT will be enabled before initialization allows OMPT support to
be initialized as part of initialization instead of back patching
initialization of OMPT support after the fact.
Post OpenMP initialization support has been generalized moves from
ompt-specific.c into ompt-general.c, since the OMPT initialization logic is no
longer implementation specific.
Patch by John Mellor-Crummey
Differential Revision: http://reviews.llvm.org/D12998
llvm-svn: 248187
This patch makes it possible for a performance tool that uses call stack
unwinding to map implementation-level call stacks from master and worker
threads into a unified global view. There are several components to this patch.
include/*/ompt.h.var
Add a new enumeration type that indicates whether the code for a master task
for a parallel region is invoked by the user program or the runtime system
Change the signature for OMPT parallel begin/end callbacks to indicate whether
the master task will be invoked by the program or the runtime system. This
enables a performance tool using call stack unwinding to handle these two
cases differently. For this case, a profiler that uses call stack unwinding
needs to know that the call path prefix for the master task may differ from
those available within the begin/end callbacks if the program invokes the
master.
kmp.h
Change the signature for __kmp_join_call to take an additional parameter
indicating the fork_context type. This is needed to supply the OMPT parallel
end callback with information about whether the compiler or the runtime
invoked the master task for a parallel region.
kmp_csupport.c
Ensure that the OMPT task frame field reenter_runtime_frame is properly set
and cleared before and after calls to fork and join threads for a parallel
region.
Adjust the code for the new signature for __kmp_join_call.
Adjust the OMPT parallel begin callback invocations to carry the extra
parameter indicating whether the program or the runtime invokes the master
task for a parallel region.
kmp_gsupport.c
Apply all of the analogous changes described for kmp_csupport.c for the GOMP
interface
Add OMPT support for the GOMP combined parallel region + loop API to
maintain the OMPT task frame field reenter_runtime_frame.
kmp_runtime.c:
Use the new information passed by __kmp_join_call to adjust the OMPT
parallel end callback invocations to carry the extra parameter indicating
whether the program or the runtime invokes the master task for a parallel
region.
ompt_internal.h:
Use the flavor of the parallel region API (GNU or Intel) to determine who
invokes the master task.
Differential Revision: http://reviews.llvm.org/D11259
llvm-svn: 242817
Jonas Hahnfeld