- Nov 14, 2016
-
-
Jonathan Peyton authored
This set of changes enables the affinity interface (Either the preexisting native operating system or HWLOC) to be dynamically set at runtime initialization. The point of this change is that we were seeing performance degradations when using HWLOC. This allows the user to use the old affinity mechanisms which on large machines (>64 cores) makes a large difference in initialization time. These changes mostly move affinity code under a small class hierarchy: KMPAffinity class Mask {} KMPNativeAffinity : public KMPAffinity class Mask : public KMPAffinity::Mask KMPHwlocAffinity class Mask : public KMPAffinity::Mask Since all interface functions (for both affinity and the mask implementation) are virtual, the implementation can be chosen at runtime initialization. Differential Revision: https://reviews.llvm.org/D26356 llvm-svn: 286890
-
- Sep 30, 2016
-
-
Jonathan Peyton authored
If affinity is not capable, then these API functions will perform the stubs version. llvm-svn: 282947
-
- Sep 12, 2016
-
-
Jonathan Peyton authored
Rather than checking KMP_CPU_SETSIZE, which doesn't exist when using Hwloc, we use the get_max_proc() function which can vary based on the operating system. For example on Windows with multiple processor groups, it might be the case that the highest bit possible in the bitmask is not equal to the number of hardware threads on the machine but something higher than that. Differential Revision: https://reviews.llvm.org/D24206 llvm-svn: 281245
-
- Sep 09, 2016
-
-
George Rokos authored
Implementation of missing OpenMP 4.0 API functions omp_get_default_device and omp_set_default_device. Also, added support for the environment variable OMP_DEFAULT_DEVICE. Differential Revision: https://reviews.llvm.org/D23587 llvm-svn: 281065
-
- Jun 16, 2016
-
-
Jonathan Peyton authored
This patch allows a user to enable Hwloc on windows. There are three main changes in here: 1.kmp.h - Move definitions/declarations out of KMP_OS_WINDOWS guard (our windows implementation of affinity) because they need to be defined when KMP_USE_HWLOC is on as well. 2.teach __kmp_set_system_affinity, __kmp_get_system_affinity, __kmp_get_proc_group, and __kmp_affinity_bind_thread how to use hwloc. 3.teach CMake how to include hwloc when building Windows Another minor change in here is to make sure that anything under KMP_USE_HWLOC is also guarded by KMP_AFFINITY_SUPPORTED as well. This is to prevent Mac builds from requiring anything from Hwloc. Differential Revision: http://reviews.llvm.org/D21441 llvm-svn: 272951
-
- Jun 14, 2016
-
-
Jonathan Peyton authored
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
-
- Jun 13, 2016
-
-
Jonathan Peyton authored
Remove static specifier from var fullMask and remove kmp_get_fullMask() routine. When iterating through procs in a mask, always check if proc is in fullMask (this check was missing in a few places). Patch by Brian Bliss. Differential Revision: http://reviews.llvm.org/D21300 llvm-svn: 272589
-
- May 31, 2016
-
-
Jonathan Peyton authored
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
-
- May 27, 2016
-
-
Jonathan Peyton authored
llvm-svn: 271006
-
- May 13, 2016
-
-
Jonathan Peyton authored
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
-
- Feb 25, 2016
-
-
Jonathan Peyton authored
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
-
Jonathan Peyton authored
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
-
- Dec 11, 2015
-
-
Jonathan Peyton authored
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
-
- Nov 30, 2015
-
-
Jonathan Peyton authored
These changes allow libhwloc to be used as the topology discovery/affinity mechanism for libomp. It is supported on Unices. The code additions: * Canonicalize KMP_CPU_* interface macros so bitmask operations are implementation independent and work with both hwloc bitmaps and libomp bitmaps. So there are new KMP_CPU_ALLOC_* and KMP_CPU_ITERATE() macros and the like. These are all in kmp.h and appropriately placed. * Hwloc topology discovery code in kmp_affinity.cpp. This uses the hwloc interface to create a libomp address2os object which the rest of libomp knows how to handle already. * To build, use -DLIBOMP_USE_HWLOC=on and -DLIBOMP_HWLOC_INSTALL_DIR=/path/to/install/dir [default /usr/local]. If CMake can't find the library or hwloc.h, then it will tell you and exit. Differential Revision: http://reviews.llvm.org/D13991 llvm-svn: 254320
-
- Sep 21, 2015
-
-
Joerg Sonnenberger authored
llvm-svn: 248204
-
- Jun 01, 2015
-
-
Jonathan Peyton authored
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
-
- May 15, 2015
-
-
Jonathan Peyton authored
Add xexpand macro to the FTN_IS_INITIAL_DEVICE api function Patch by Davide Italiano Differential Revision: http://reviews.llvm.org/D9798 llvm-svn: 237472
-
- Apr 02, 2015
-
-
Andrey Churbanov authored
Replace some unsafe API calls with safe alternatives on Windows, prepare code for similar actions on other platforms - wrap unsafe API calls into macros. llvm-svn: 233915
-
- Feb 20, 2015
-
-
Andrey Churbanov authored
llvm-svn: 230030
-
- Feb 10, 2015
-
-
Andrey Churbanov authored
llvm-svn: 228730
-
- Jan 29, 2015
-
-
Andrey Churbanov authored
llvm-svn: 227450
-
- Jan 27, 2015
-
-
Andrey Churbanov authored
llvm-svn: 227207
-
Andrey Churbanov authored
Replaces KMP_OS_WINDOWS && KMP_ARCH_X86_64 or any combination of those two options with the feature macro KMP_GROUP_AFFINITY. llvm-svn: 227199
-
- Oct 07, 2014
-
-
Jim Cownie authored
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
-
- Aug 05, 2014
-
-
Jim Cownie authored
CMAKE buld system should meet everyone's requirements. Enhanced CMake Build System Commit * Supports Linux, Mac, Windows, and Intel® Xeon Phi builds * Supports building with gcc, icc, clang, and Visual Studio compilers * Supports bulding "fat" libraries on OS/X with clang * Details and documentation on how to use build system are in Build_With_CMake.txt * To use the old CMake build system (corresponds to CMakeLists.txt.old), just rename CMakeLists.txt to CMakeLists.txt.other and rename CMakeLists.txt.old to CMakeLists.txt llvm-svn: 214850
-
- Feb 28, 2014
-
-
Alp Toker authored
Port the OpenMP runtime to FreeBSD along with associated build system changes. Also begin to generalize affinity capabilities so they aren't tied explicitly to Windows and Linux. The port builds with stock clang and gmake and has no additional runtime dependencies. All but a handful of the validation suite tests are now passing on FreeBSD 10 x86_64. llvm-svn: 202478
-
- Feb 24, 2014
-
-
Alp Toker authored
llvm-svn: 202018
-
- Dec 23, 2013
-
-
Jim Cownie authored
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
-
- Sep 27, 2013
-
-
Jim Cownie authored
llvm-svn: 191506
-