Age | Commit message (Collapse) | Author | Files | Lines |
|
------------------------------------------------------------------------
r318848 | hahnfeld | 2017-11-22 09:15:20 -0800 (Wed, 22 Nov 2017) | 7 lines
Fix for OMP doacross implementation on Power
Power has a weak consistency model so we need memory barriers to
make writes (both from runtime and from user code) available for
all threads.
Differential Revision: https://reviews.llvm.org/D40175
------------------------------------------------------------------------
llvm-svn: 319057
|
|
------------------------------------------------------------------------
r318658 | achurbanov | 2017-11-20 08:00:42 -0800 (Mon, 20 Nov 2017) | 4 lines
Fixed OMP doacross implementation on 32-bit platforms.
Differential Revision: https://reviews.llvm.org/D40171
------------------------------------------------------------------------
llvm-svn: 319053
|
|
------------------------------------------------------------------------
r317115 | jlpeyton | 2017-11-01 12:44:42 -0700 (Wed, 01 Nov 2017) | 19 lines
[OpenMP] Fix race condition in omp_init_lock
This is a partial fix for bug 34050.
This prevents callers of omp_set_lock (which does not hold __kmp_global_lock)
from ever seeing an uninitialized version of __kmp_i_lock_table.table.
It does not solve a use-after-free race condition if omp_set_lock obtains a
pointer to __kmp_i_lock_table.table before it is updated and then attempts to
dereference afterwards. That race is far less likely and can be handled in a
separate patch.
The unit test usually segfaults on the current trunk revision. It passes with
the patch.
Patch by Adam Azarchs
Differential Revision: https://reviews.llvm.org/D39439
------------------------------------------------------------------------
llvm-svn: 318178
|
|
------------------------------------------------------------------------
r316452 | jlpeyton | 2017-10-24 09:10:09 -0700 (Tue, 24 Oct 2017) | 9 lines
Disable threadprivate data cleanup if runtime is terminating
The problem is due to the runtime's threadprivate cleanup code which tries to
access data that was already destroyed by one of the root threads.
__kmp_init_gtid is used as a checker here since it is set to false before actual
resource cleanup is done in __kmp_cleanup().
Patch by Hansang Bae
------------------------------------------------------------------------
llvm-svn: 318176
|
|
------------------------------------------------------------------------
r311269 | jlpeyton | 2017-08-19 16:53:36 -0700 (Sat, 19 Aug 2017) | 8 lines
Use va_copy instead of __va_copy to fix building libomp against musl libc
Fixes https://bugs.llvm.org/show_bug.cgi?id=34040
Patch by Peter Levine
Differential Revision: https://reviews.llvm.org/D36343
------------------------------------------------------------------------
llvm-svn: 318175
|
|
------------------------------------------------------------------------
r309875 | jlpeyton | 2017-08-02 13:06:32 -0700 (Wed, 02 Aug 2017) | 11 lines
Move lock acquire/release functions in task deque cleanup code
The original locations can be reached without initializing the lock variable
(td_deque_lock), so it is potentially unsafe. It is guaranteed that the lock
is initialized if the deque (td_deque) is not NULL, and lock functions can be
safely called.
Patch by Hansang Bae
Differential Revision: https://reviews.llvm.org/D36017
------------------------------------------------------------------------
llvm-svn: 318171
|
|
------------------------------------------------------------------------
r314513 | hahnfeld | 2017-09-29 06:53:03 -0700 (Fri, 29 Sep 2017) | 3 lines
[test] Fix uninitialized memory in omp_taskloop_grainsize.c
result was never initialized to zero which sometimes failed the test.
------------------------------------------------------------------------
llvm-svn: 315353
|
|
------------------------------------------------------------------------
r309115 | hahnfeld | 2017-07-26 06:55:00 -0700 (Wed, 26 Jul 2017) | 15 lines
[CMake] Disable building libomptarget and add CMake switch
Introduce OPENMP_ENABLE_LIBOMPTARGET which defaults to OFF at the moment.
libomptarget is not yet ready for prime time:
- Offloading to NVIDIA GPUs is not completed yet (compiler, device RTL)
- The generic ELF plugin for offloading to the host (meant for testing)
uses a single instance of the OpenMP runtime (libomp). That is why
omp_is_initial_device() returns 1 which makes the tests fail.
Because of these reasons, we want to disable building (and testing!)
for release 5.0.
See https://bugs.llvm.org/show_bug.cgi?id=33859
Differential Revision: https://reviews.llvm.org/D35719
------------------------------------------------------------------------
llvm-svn: 309126
|
|
Differential Revision: https://reviews.llvm.org/D35490
llvm-svn: 308423
|
|
Summary:
The kmp_os.h header is defining the `PAGE_SIZE` macro unconditionally,
even while it is only used directly after its definition, for the
Windows implementation of the `KMP_GET_PAGE_SIZE()` macro.
On at least FreeBSD, but likely all other BSDs too, this macro conflicts
with the one defined in system headers, so remove it, since nothing else
uses it. Make all Unixes use `getpagesize()` instead, and use
`GetSystemInfo()` for the Windows case.
Reviewers: jlpeyton, jcownie, emaste, AndreyChurbanov
Reviewed By: AndreyChurbanov
Subscribers: AndreyChurbanov, hfinkel, zturner
Differential Revision: https://reviews.llvm.org/D35072
llvm-svn: 308355
|
|
We do not have GOMP interface support for taskloop yet.
llvm-svn: 308351
|
|
Summary:
Taskloop implementation is extended by using recursive task scheduling.
Envirable KMP_TASKLOOP_MIN_TASKS added as a manual threshold for the user
to switch from recursive to linear tasks scheduling.
Details:
* The calculations for the loop parameters are moved from __kmp_taskloop_linear
upper level
* Initial calculation is done in the __kmpc_taskloop, further range splitting
is done in the __kmp_taskloop_recur.
* Added threshold to switch from recursive to linear tasks scheduling;
* One half of split range is scheduled as an internal task which just moves
sub-range parameters to the stealing thread that continues recursive
scheduling (if number of tasks still enough), the other half is processed
recursively;
* Internal task duplication routine fixed to assign parent task, that was not
needed when all tasks were scheduled by same thread, but is needed now.
Patch by Andrey Churbanov
Differential Revision: https://reviews.llvm.org/D35273
llvm-svn: 308338
|
|
Patch by Terry Wilmarth
Differential Revision: https://reviews.llvm.org/D35535
llvm-svn: 308298
|
|
Differential Revision: https://reviews.llvm.org/D35497
llvm-svn: 308274
|
|
The internal details of this setting are not meant to be user visible and only create confusion.
Differential Revision: https://reviews.llvm.org/D35269
llvm-svn: 308189
|
|
Changes are: got all atomics to accept volatile pointers that allowed
to simplify many type conversions. Windows specific code fixed correspondingly.
Differential Revision: https://reviews.llvm.org/D35417
llvm-svn: 308164
|
|
The first bit is actually the "untied" flag. That is why the condition was
wrong and has to be inverted to set the flag correctly.
Found and initial patch by Simon Convent!
llvm-svn: 307899
|
|
Summary:
On Unix, a .S file is normally an assembly source which must be
preprocessed with a C preprocessor, while a .s file is "plain" assembly.
The former is handled by the compiler driver (cc), the latter is
directly passed to the assembler binary (as).
Because z_Linux_asm.s is supposed to be preprocessed, rename it to .S,
so it can be automatically picked up correctly by build systems.
Reviewers: AndreyChurbanov, emaste, jlpeyton
Reviewed By: AndreyChurbanov
Subscribers: mgorny, openmp-commits
Differential Revision: https://reviews.llvm.org/D35171
llvm-svn: 307680
|
|
llvm-svn: 307474
|
|
While importing libomp into the FreeBSD base system we encountered
Clang warnings that "'register' storage class specifier is deprecated
and incompatible with C++1z [-Wdeprecated-register]".
Differential Revision: https://reviews.llvm.org/D35124
llvm-svn: 307441
|
|
GNU ld ignores duplicates, but lld produces a warning.
Differential Revision: https://reviews.llvm.org/D35121
llvm-svn: 307399
|
|
Address user message bug where the messages were sending users to Intel's
website instead of the LLVM OpenMP runtime websites.
Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=32892
Differential Revision: https://reviews.llvm.org/D35018
llvm-svn: 307206
|
|
Changes are: replaced C-style casts with cons_cast and reinterpret_cast;
type of several counters changed to signed; type of parameters of 32-bit and
64-bit AND and OR intrinsics changes to unsigned; changed files formatted
using clang-format version 3.8.1.
Differential Revision: https://reviews.llvm.org/D34759
llvm-svn: 307020
|
|
I've found it very difficult to get test/parallel/omp_nested.c to pass
consistently across my build environments. The problem is that it creates N^2
threads (it is testing nested parallel regions), and that often exceeds the
thread limits on systems with many cores. We do raise the process limits in
lit, and that often helps, but if running lit with a smaller number of threads
or on a system where we're otherwise resource constrained, this particular test
tends to fail (because the runtime cannot create a sufficient number of
threads).
This seems to work: if the maximum number of threads is more than some small
number, then cap the number of threads used for the parallel region. The choice
of 4 here is somewhat arbitrary.
Differential Revision: https://reviews.llvm.org/D32033
llvm-svn: 306357
|
|
Summary: On BSDs, there is no `libdl.so`, and functions like `dlopen`
are implemented in the main C library instead. Use the `CMAKE_DL_LIBS`
variable instead of hardcoding a dependency on the `dl` library.
Reviewers: grokos, joerg, emaste
Reviewed By: emaste
Subscribers: jlpeyton, mgorny, openmp-commits
Differential Revision: https://reviews.llvm.org/D34632
llvm-svn: 306319
|
|
Reset affinity to none (false for proc-bind-var) so that threads in the child
processes are not bound tightly, unless the user explicitly sets this in
KMP_AFFINITY/OMP_PROC_BIND, in child processes. This can improve
performance for scripting languages which fork for parallelism like Python's
multiprocessing module.
Differential Revision: https://reviews.llvm.org/D34154
llvm-svn: 305513
|
|
Differential Revision: https://reviews.llvm.org/D34119
llvm-svn: 305307
|
|
If OpenMP is initialized before fork()-ing occurs and affinity is set to
something like compact, then the master thread will be pinned to a single HW
thread/core after initialization. If the master (or any other thread) then
forks N processes, all N processes will then be pinned to that same single HW
thread/core. To reset the affinity for the new child process, the atfork
handler for the child process can call kmp_set_thread_affinity_mask_initial()
to reset its affinity to the initial affinity of the application before it
re-initializes libomp. The parent process will not be affected and still
keeps its affinity setting.
Differential Revision: https://reviews.llvm.org/D34118
llvm-svn: 305306
|
|
Release mode.
llvm-svn: 305090
|
|
Fix static initializers to use the proper unlocked value for the poll
field of the tas and futex locks.
Patch by Terry Wilmarth
Differential Revision: https://reviews.llvm.org/D33794
llvm-svn: 304828
|
|
schedule(simd:runtime) - library part. Compiler generation should use newly
introduced scheduling kinds kmp_sch_guided_simd = 46, kmp_sch_runtime_simd = 47,
as parameters to __kmpc_dispatch_init_* entries.
Differential Revision: https://reviews.llvm.org/D31602
llvm-svn: 304724
|
|
Thanks to Sergey Dmitriev for submitting the patch.
Differential Revision: https://reviews.llvm.org/D33851
llvm-svn: 304601
|
|
Differential Revision: https://reviews.llvm.org/D31421
llvm-svn: 304443
|
|
Some code was restructured to move it under KMP_DEBUG. The rest is
formatting changes to fix some things broken by clang-format
Patch by Terry Wilmarth
Differential Revision: https://reviews.llvm.org/D33744
llvm-svn: 304438
|
|
With these settings, the create_hwloc_map() method was being called causing an
assert(). After some consideration, it was determined that disabling affinity
explicitly should just disable hwloc as well. i.e., KMP_AFFINITY overrides
KMP_TOPOLOGY_METHOD. This lets the user know that the Hwloc mechanism is being
ignored when KMP_AFFINITY=disabled.
Differential Revision: https://reviews.llvm.org/D33208
llvm-svn: 304344
|
|
This change checks if the initial affinity mask is equal to exactly one
Windows processor group's affinity mask. If it is, then the code does not
respect the initial affinity mask and uses the entire machine instead.
The reasoning behind this is that, by default, Windows assigns exactly one
processor group as the initial affinity mask even when there are multiple
Windows processor groups available. User's typically want to use the whole
machine, so we ignore this special case and use the entire machine.
If the initial affinity mask is a proper subset of one group, or spans multiple
groups, then the initial affinity mask is respected since we can assume that the
operating system did not assign this initial affinity mask. This change only
affects machines with multiple processor groups
Differential Revision: https://reviews.llvm.org/D33210
llvm-svn: 304343
|
|
An assert() was being tripped when KMP_AFFINITY=respect + Multiple Processor
Groups. Let __kmp_affinity_create_proc_group_map() function be able to create
address2os object which contains a single group by deleting restriction that
process affinity mask must span multiple groups.
llvm-svn: 303101
|
|
llvm-svn: 303086
|
|
llvm-svn: 303079
|
|
This patch contains the clang-format and cleanup of the entire code base. Some
of clang-formats changes made the code look worse in places. A best effort was
made to resolve the bulk of these problems, but many remain. Most of the
problems were mangling line-breaks and tabbing of comments.
Patch by Terry Wilmarth
Differential Revision: https://reviews.llvm.org/D32659
llvm-svn: 302929
|
|
This patch chagnes the plugin interface so that:
1) future plugins can take advantage of systems with shared CPU/device storage
2) instead of using base addresses, target regions are launched by providing target addresseds and base offsets explicitly.
Differential revision: https://reviews.llvm.org/D33028
llvm-svn: 302663
|
|
Differential Revision: https://reviews.llvm.org/D32562
Thanks to Sergey Dmitriev for submitting the patch.
llvm-svn: 301577
|
|
Older Hwloc libraries (< 1.10.0) don't offer the HWLOC_OBJ_NUMANODE nor
HWLOC_OBJ_PACKAGE types. Instead they are named HWLOC_OBJ_NODE and
HWLOC_OBJ_SOCKET instead. This patch just defines the newer names based on
the older names when using an older Hwloc.
Differential Revision: https://reviews.llvm.org/D32496
llvm-svn: 301349
|
|
Differential Revision: https://reviews.llvm.org/D32321
llvm-svn: 301321
|
|
Differential Revision: https://reviews.llvm.org/D32490
llvm-svn: 301318
|
|
Differential Revision: https://reviews.llvm.org/D32326
llvm-svn: 301076
|
|
Differential Revision: https://reviews.llvm.org/D32325
llvm-svn: 301075
|
|
Differential Revision: https://reviews.llvm.org/D32327
llvm-svn: 301074
|
|
Patch by Ni Hui.
Differential Revision: https://reviews.llvm.org/D31923
llvm-svn: 300448
|
|
Differential Revision: https://reviews.llvm.org/D31600
llvm-svn: 300220
|