Add build option LIBOMP_OMP_VERSION=50, 5.0 headers, and add the year/month
associated with OpenMP 5.0 in relevant source locations. Also, remove the
deprecated LIBOMP_OMP_VERSION=41 option.
Patch by Olga Malysheva
Differential Revision: https://reviews.llvm.org/D30450
llvm-svn: 297083
OpenMP 4.1 is now OpenMP 4.5. Any mention of 41 or 4.1 is replaced with
45 or 4.5. Also, if the CMake option LIBOMP_OMP_VERSION is 41, CMake warns that
41 is deprecated and to use 45 instead.
llvm-svn: 272687
The problem is the lack of dispatch buffers when thousands of loops with nowait,
about 10 iterations each, are executed by hundreds of threads. We only have
built-in 7 dispatch buffers, but there is a need in dozens or hundreds of
buffers.
The problem can be fixed by setting KMP_MAX_DISP_BUF to bigger value. In order
to give users same possibility I changed build-time control into run-time one,
adding API just in case.
This change adds an environment variable KMP_DISP_NUM_BUFFERS and a new API
function kmp_set_disp_num_buffers(int num_buffers).
The KMP_DISP_NUM_BUFFERS envirable works only before serial initialization,
because during the serial initialization we already allocate buffers for the hot
team, so it is too late to change the number of buffers later (or we need to
reallocate buffers for all teams which sounds too complicated). The
kmp_set_defaults() routine does not work for this envirable, because it calls
serial initialization before reading the parameter string. So a new routine,
kmp_set_disp_num_buffers(), is created so that it can set our internal global
variable before the library initialization. If both the envirable and API used
the envirable wins.
Differential Revision: http://reviews.llvm.org/D20697
llvm-svn: 271318
This change adds a new entry point,
kmp_aligned_malloc(size_t size, size_t alignment), an entry point corresponding
to kmp_malloc() but with the capability to return aligned memory as well.
Other allocator routines have been adjusted so that kmp_free() can be used for
freeing memory blocks allocated by any kmp_*alloc() routine, including the new
kmp_aligned_malloc() routine.
Differential Revision: http://reviews.llvm.org/D19814
llvm-svn: 269365
This change introduces the new OpenMP 4.5 affinity api surrounding
OpenMP Places. There are six new entry points:
Typically called in serial region:
* omp_get_num_places - returns the number of places available to the execution
environment in the place list.
* omp_get_place_num_procs - returns the number of processors available to the
execution environment in the specified place.
* omp_get_place_proc_ids - returns the numerical identifiers of the processors
available to the execution environment in the specified place.
Typically called inside parallel region:
* omp_get_place_num - returns the place number of the place to which the
encountering thread is bound.
* omp_get_partition_num_places - returns the number of places in the place
partition of the innermost implicit task.
* omp_get_partition_place_nums - returns the list of place numbers
corresponding to the places in the place-var ICV of the innermost
implicit task.
Differential Revision: http://reviews.llvm.org/D17417
llvm-svn: 261915
The maximum task priority value is read from envirable: OMP_MAX_TASK_PRIORITY.
But as of now, nothing is done with it. We just handle the environment variable
and add the new api: omp_get_max_task_priority() which returns that value or
zero if it is not set.
Differential Revision: http://reviews.llvm.org/D17411
llvm-svn: 261908
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
Current clang trunk reports _OPENMP to be 201307 = OpenMP 4.0. It doesn't
recognize '#pragma omp declare target' though (patch still pending) and
therefore fails compilation.
Differential Revision: http://reviews.llvm.org/D16631
llvm-svn: 259026
This change set includes all changes to make the code conform to the OMP 4.5 specification:
* Removed hint / hinted_init definitions from include/40 files
* Hint values are powers of 2 to enable composition (4.5 spec)
* Hinted lock initialization functions were renamed (4.5 spec)
kmp_init_lock_hinted -> omp_init_lock_with_hint
kmp_init_nest_lock_hinted -> omp_init_nest_lock_with_hint
* __kmpc_critical_section_with_hint was added to support a critical section with
a hint (4.5 spec)
* __kmp_map_hint_to_lock was added to convert a hint (possibly a composite) to
an internal lock type
* kmpc_init_lock_with_hint and kmpc_init_nest_lock_with_hint were added as
internal entries for the hinted lock initializers. The preivous internal
functions (__kmp_init*) were moved to kmp_csupport.c and reused in multiple
places
* Added the two init functions to dllexports
* KMP_USE_DYNAMIC_LOCK is turned on if OMP_41_ENABLED is turned on
Differential Revision: http://reviews.llvm.org/D15205
llvm-svn: 255376
* Added a new user TSX lock implementation, RTM, This implementation is a
light-weight version of the adaptive lock implementation, omitting the
back-off logic for deciding when to specualte (or not). The fall-back lock is
still the queuing lock.
* Changed indirect lock table management. The data for indirect lock management
was encapsulated in the "kmp_indirect_lock_table_t" type. Also, the lock table
dimension was changed to 2D (was linear), and each entry is a
kmp_indirect_lock_t object now (was a pointer to an object).
* Some clean up in the critical section code
* Removed the limits of the tuning parameters read from KMP_ADAPTIVE_LOCK_PROPS
* KMP_USE_DYNAMIC_LOCK=1 also turns on these two switches:
KMP_USE_TSX, KMP_USE_ADAPTIVE_LOCKS
Differential Revision: http://reviews.llvm.org/D15204
llvm-svn: 255375
The patch adds support for ompt_event_task_switch into LLVM/OpenMP. Note that
the patch has also updated the signature of ompt_event_task_switch to
ompt_task_pair_callback_t (rather than the previous ompt_task_switch_callback_t).
Patch by Harald Servat
Differential Revision: http://reviews.llvm.org/D14566
llvm-svn: 252761
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 change deletes the Makefile+Perl build system and all files used by it
which aren't used by the CMake build system. This included many Perl files,
*.mk files, iomp* files. This change also updates the README's and
index.html to instruct the user to use the CMake build system. All mentioning
of the Perl+Makefile based system are removed.
Differential Revision: http://reviews.llvm.org/D12331
llvm-svn: 247583
Currently, the libomp CMake build system uses a Perl script to configure files
(tools/expand-vars.pl). This patch replaces the use of the Perl script by using
CMake's configure_file() function. The major changes include:
1. *.var has every $KMP_* variable changed to @LIBOMP_*@
2. kmp_config.h.cmake is a new file which contains all the feature macros and
#cmakedefine lines
3. Most of the -D lines have been moved from LibompDefinitions.cmake but some
OS specific MACROs (e.g., _GNU_SOURCE) remain.
4. All expand-vars.pl related logic is removed from the CMake files.
One important note about this change is that it breaks the old Perl+Makefile
build system because it can't create kmp_config.h properly.
Differential Review: http://reviews.llvm.org/D12211
llvm-svn: 246314
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
r242052 changed the name of OMPT placeholder functions to move them from
the omp_ name space to the ompt_ name space. This patch moves the names of the
types of these functions into the OMPT name space as well.
Patch by John Mellor-Crummey
Differential Revision: http://reviews.llvm.org/D11171
llvm-svn: 242155
1.) in kmp_csupport.c, move computation of parameters only needed for OMPT tracing
inside a conditional to reduce overhead if not receiving ompt_event_master_begin
callbacks.
2.) in kmp_gsupport.c, remove spurious reset of OMPT reenter_runtime_frame (which
is set in its caller, GOMP_parallel_start correct placement of #if OMP_TRACE so
that state is maintained even if tracing support not included.
3.) in z_Linux_util.c, add architecture independent support for OMPT by setting
and resetting OMPT's exit_frame_ptr before and after invoking a microtask.
4.) On the Intel MIC, the loader refuses to retain static symbols in the
libomp.so shared library, even though tools need them. The loader could not be
bullied into doing so. To accommodate this, I changed the visibility of OMPT
placeholder functions to public. This required additions in exports.so.txt,
adding extern "C" scoping in ompt-general.c so that the public placeholder
symbols won't be mangled.
Patch by John Mellor-Crummey
Differential Revision: http://reviews.llvm.org/D11062
llvm-svn: 242052
understand that this is not friendly, and are working to change our
internal code-development to make it easier to make development
features available more frequently and in finer (more functional)
chunks. Unfortunately we haven't got that in place yet, and unpicking
this into multiple separate check-ins would be non-trivial, so please
bear with me on this one. We should be better in the future.
Apologies over, what do we have here?
GGC 4.9 compatibility
--------------------
* We have implemented the new entrypoints used by code compiled by GCC
4.9 to implement the same functionality in gcc 4.8. Therefore code
compiled with gcc 4.9 that used to work will continue to do so.
However, there are some other new entrypoints (associated with task
cancellation) which are not implemented. Therefore user code compiled
by gcc 4.9 that uses these new features will not link against the LLVM
runtime. (It remains unclear how to handle those entrypoints, since
the GCC interface has potentially unpleasant performance implications
for join barriers even when cancellation is not used)
--- new parallel entry points ---
new entry points that aren't OpenMP 4.0 related
These are implemented fully :-
GOMP_parallel_loop_dynamic()
GOMP_parallel_loop_guided()
GOMP_parallel_loop_runtime()
GOMP_parallel_loop_static()
GOMP_parallel_sections()
GOMP_parallel()
--- cancellation entry points ---
Currently, these only give a runtime error if OMP_CANCELLATION is true
because our plain barriers don't check for cancellation while waiting
GOMP_barrier_cancel()
GOMP_cancel()
GOMP_cancellation_point()
GOMP_loop_end_cancel()
GOMP_sections_end_cancel()
--- taskgroup entry points ---
These are implemented fully.
GOMP_taskgroup_start()
GOMP_taskgroup_end()
--- target entry points ---
These are empty (as they are in libgomp)
GOMP_target()
GOMP_target_data()
GOMP_target_end_data()
GOMP_target_update()
GOMP_teams()
Improvements in Barriers and Fork/Join
--------------------------------------
* Barrier and fork/join code is now in its own file (which makes it
easier to understand and modify).
* Wait/release code is now templated and in its own file; suspend/resume code is also templated
* There's a new, hierarchical, barrier, which exploits the
cache-hierarchy of the Intel(r) Xeon Phi(tm) coprocessor to improve
fork/join and barrier performance.
***BEWARE*** the new source files have *not* been added to the legacy
Cmake build system. If you want to use that fixes wil be required.
Statistics Collection Code
--------------------------
* New code has been added to collect application statistics (if this
is enabled at library compile time; by default it is not). The
statistics code itself is generally useful, the lightweight timing
code uses the X86 rdtsc instruction, so will require changes for other
architectures.
The intent of this code is not for users to tune their codes but
rather
1) For timing code-paths inside the runtime
2) For gathering general properties of OpenMP codes to focus attention
on which OpenMP features are most used.
Nested Hot Teams
----------------
* The runtime now maintains more state to reduce the overhead of
creating and destroying inner parallel teams. This improves the
performance of code that repeatedly uses nested parallelism with the
same resource allocation. Set the new KMP_HOT_TEAMS_MAX_LEVEL
envirable to a depth to enable this (and, of course, OMP_NESTED=true
to enable nested parallelism at all).
Improved Intel(r) VTune(Tm) Amplifier support
---------------------------------------------
* The runtime provides additional information to Vtune via the
itt_notify interface to allow it to display better OpenMP specific
analyses of load-imbalance.
Support for OpenMP Composite Statements
---------------------------------------
* Implement new entrypoints required by some of the OpenMP 4.1
composite statements.
Improved ifdefs
---------------
* More separation of concepts ("Does this platform do X?") from
platforms ("Are we compiling for platform Y?"), which should simplify
future porting.
ScaleMP* contribution
---------------------
Stack padding to improve the performance in their environment where
cross-node coherency is managed at the page level.
Redesign of wait and release code
---------------------------------
The code is simplified and performance improved.
Bug Fixes
---------
*Fixes for Windows multiple processor groups.
*Fix Fortran module build on Linux: offload attribute added.
*Fix entry names for distribute-parallel-loop construct to be consistent with the compiler codegen.
*Fix an inconsistent error message for KMP_PLACE_THREADS environment variable.
llvm-svn: 219214
This release use aligns with Intel(r) Composer XE 2013 SP1 Product Update 2
New features
* The library can now be built with clang (though wiht some
limitations since clang does not support 128 bit floats)
* Support for Vtune analysis of load imbalance
* Code contribution from Steven Noonan to build the runtime for ARM*
architecture processors
* First implementation of runtime API for OpenMP cancellation
Bug Fixes
* Fixed hang on Windows (only) when using KMP_BLOCKTIME=0
llvm-svn: 197914
