This is a refactoring of the task_team code that more elegantly handles the two
task_team case. Two task_teams per team are kept in use for the lifetime of the
team. Thus no reference counting is needed.
Differential Revision: http://reviews.llvm.org/D13993
llvm-svn: 252082
The th.th_task_state for the master thread at the start of a nested parallel
should not be zeroed in __kmp_allocate_team() because it is later put in the
stack of states in __kmp_fork_call() for further re-use after exiting the
nested region. It is zeroed after being put in the stack.
Differential Revision: http://reviews.llvm.org/D13702
llvm-svn: 250847
Without this fix, cancellation requests in one parallel region cause
cancellation of the second region even though the second one was
not intended to be cancelled.
llvm-svn: 250727
These changes improve the wait/release mechanism for threads spinning in
barriers that are handling tasks while spinnin by providing feedback to the
barriers about any task stealing that occurs.
Differential Revision: http://reviews.llvm.org/D13353
llvm-svn: 249711
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 only triggered when built in debug mode with OMPT enabled:
__kmp_wait_template expected the state of the current thread to be either
ompt_state_idle or ompt_state_wait_barrier{,_implicit,_explicit}.
Patch by Jonas Hahnfeld
Differential Revision: http://reviews.llvm.org/D12754
llvm-svn: 247339
Some of this is improvement to code suggested by Hal Finkel. Four changes here:
1.Cleanup of hierarchy code to handle all hierarchy cases whether affinity is available or not
2.Separated this and other classes and common functions out to a header file
3.Added a destructor-like fini function for the hierarchy (and call in __kmp_cleanup)
4.Remove some redundant code that is hopefully no longer needed
Differential Revision: http://reviews.llvm.org/D12449
llvm-svn: 247326
The fix is to make b_arrived flag 64 bit in both structures - kmp_balign_team_t
and kmp_balign_t. Otherwise when flag in kmp_balign_team_t wrapped over
UINT_MAX the library hangs.
Differential Revision: http://reviews.llvm.org/D12563
llvm-svn: 247320
Conditionally include the fork_context parameter to __kmp_join_call()
only if OMPT_SUPPORT=1
Differential Revision: http://reviews.llvm.org/D12495
llvm-svn: 246460
This removes some statistics counters and timers which were not used,
adds new counters and timers for some language features that were not
monitored previously and separates the counters and timers into those
which are of interest for investigating user code and those which are
only of interest to the developer of the runtime itself.
The runtime developer statistics are now ony collected if the
additional #define KMP_DEVELOPER_STATS is set.
Additional user statistics which are now collected include:
* Count of nested parallelism (omp parallel inside a parallel region)
* Count of omp distribute occurrences
* Count of omp teams occurrences
* Counts of task related statistics (taskyield, task execution, task
cancellation, task steal)
* Values passed to omp_set_numtheads
* Time spent in omp single and omp master
None of this affects code compiled without stats gathering enabled,
which is the normal library build mode.
This also fixes the CMake build by linking to the standard c++ library
when building the stats library as it is a requirement. The normal library
does not have this requirement and its link phase is left alone.
Differential Revision: http://reviews.llvm.org/D11759
llvm-svn: 244677
Compiling simple testcase with g++ and linking it to the LLVM OpenMP runtime
compiled in debug mode trips an assertion that produces a fatal error. When
the assertion is skipped, the program runs successfully to completion and
produces the same answer as the sequential code. Intel will restore the
assertion with a patch that fixes the issues that cause it to trip.
Patch by John Mellor-Crummey
Differential Revision: http://reviews.llvm.org/D11269
llvm-svn: 243032
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
These changes enable external debuggers to conveniently interface with
the LLVM OpenMP Library. Structures are added which describe the important
internal structures of the OpenMP Library e.g., teams, threads, etc.
This feature is turned on by default (CMake variable LIBOMP_USE_DEBUGGER)
and can be turned off with -DLIBOMP_USE_DEBUGGER=off.
Differential Revision: http://reviews.llvm.org/D10038
llvm-svn: 241832
Fix OMPT support for barriers so that state changes occur even if OMPT_TRACE turned off.
These state changes are needed by performance tools that use callbacks for either
ompt_event_wait_barrier_begin or ompt_event_wait_barrier_end. Change ifdef flag to OMPT_BLAME
for callbacks ompt_event_wait_barrier_begin or ompt_event_wait_barrier_end rather than
OMPT_TRACE -- they were misclassified. Without this patch, when the runtime is compiled with
LIBOMP_OMPT_SUPPORT=true, LIBOMP_OMPT_BLAME=true, and LIBOMP_OMPT_TRACE=false, and a callback
is registered for either ompt_event_wait_barrier_begin or ompt_event_wait_barrier_end, then an
assertion will trip. Fix the scoping of one OMPT_TRACE ifdef, which should not have surrounded
an update of an OMPT state. Add a missing initialization of an OMPT task id for an implicit task.
Patch by John Mellor-Crummey
Differential Revision: http://reviews.llvm.org/D10759
llvm-svn: 240970
I tried to compile with Visual Studio using CMake and found these two sections of code
causing problems for Visual Studio. The first one removes the use of variable length
arrays by instead using KMP_ALLOCA(). The second part eliminates a redundant cpuid
assembly call by using the already existing __kmp_x86_cpuid() call instead.
llvm-svn: 240290
As an ongoing effort to sanitize the openmp code, these changes move
variables under already existing macro guards.
Patch by Jack Howarth
llvm-svn: 239331
As an ongoing effort to sanitize the openmp code, these changes remove unused variables
by adding proper macros around both variables and functions.
Patch by Jack Howarth
llvm-svn: 239330
As an ongoing effort to sanitize the openmp code, these changes remove unused functions.
The unused functions are:
__kmp_fini_allocator_thread(), __kmp_env_isDefined(), __kmp_strip_quotes(),
__kmp_convert_to_seconds(), and __kmp_convert_to_nanoseconds().
Patch by Jack Howarth
llvm-svn: 239323
These changes are mostly in comments, but there are a few
that aren't. Change libiomp5 => libomp everywhere. One internal
function name is changed in kmp_gsupport.c, and in kmp_i18n.c, the
static char[] variable 'name' is changed to "libomp".
llvm-svn: 238712
A while back, Hal suggested updating the GUIDEDLL_EXPORTS macro guard to
a more descriptive name. It represents a dynamic library build so
KMP_DYNAMIC_LIB is a more suitable name.
Differential Revision: http://reviews.llvm.org/D9899
llvm-svn: 238221
The fix simply syncs up the new threads to have the same task_state and
task_team as the old threads. The master thread is skipped,
because it shouldn't at this point have the team's task_team value yet
-- it should still have parent_team's task_team. It gets pointed at
the new team's task_team later, after __kmp_allocate_team returns, and
the master has stored a memo of it's old task_state.
llvm-svn: 237916
Jonathan Peyton