|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4 |
|
| #
a01d274f |
| 19-May-2022 |
AndreyChurbanov <[email protected]> |
[OpenMP][libomp] Fix /dev/shm pollution after forked child process terminates
Made library registration conditional and skip it in the __kmp_atfork_child handler, postponed it till middle initializa
[OpenMP][libomp] Fix /dev/shm pollution after forked child process terminates
Made library registration conditional and skip it in the __kmp_atfork_child handler, postponed it till middle initialization in the child. This fixes the problem of applications those use e.g. popen/pclose which terminate the forked child process.
Differential Revision: https://reviews.llvm.org/D125996
show more ...
|
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
| #
1dd79716 |
| 21-Oct-2021 |
Peyton, Jonathan L <[email protected]> |
[OpenMP][libomp] Add support for offline CPUs in Linux
If some CPUs are offline, then make sure they are not included in the fullMask even if norespect is given to KMP_AFFINITY.
Differential Revisi
[OpenMP][libomp] Add support for offline CPUs in Linux
If some CPUs are offline, then make sure they are not included in the fullMask even if norespect is given to KMP_AFFINITY.
Differential Revision: https://reviews.llvm.org/D112274
show more ...
|
| #
c46becf5 |
| 17-Nov-2021 |
Jonathan Peyton <[email protected]> |
[OpenMP][libomp][NFC] Remove non-ASCII apostrophe in comment
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1 |
|
| #
8b81524c |
| 30-Jul-2021 |
AndreyChurbanov <[email protected]> |
[OpenMP][NFC] libomp: silence warnings on unused variables.
Put declarations/definitions of unused variables under corresponding macros to silence clang build warnings.
Differential Revision: https
[OpenMP][NFC] libomp: silence warnings on unused variables.
Put declarations/definitions of unused variables under corresponding macros to silence clang build warnings.
Differential Revision: https://reviews.llvm.org/D106608
show more ...
|
|
Revision tags: llvmorg-14-init |
|
| #
d8e4cb91 |
| 15-Jul-2021 |
Terry Wilmarth <[email protected]> |
[OpenMP] libomp: Add new experimental barrier: two-level distributed barrier
Two-level distributed barrier is a new experimental barrier designed for Intel hardware that has better performance in so
[OpenMP] libomp: Add new experimental barrier: two-level distributed barrier
Two-level distributed barrier is a new experimental barrier designed for Intel hardware that has better performance in some cases than the default hyper barrier.
This barrier is designed to handle fine granularity parallelism where barriers are used frequently with little compute and memory access between barriers. There is no need to use it for codes with few barriers and large granularity compute, or memory intensive applications, as little difference will be seen between this barrier and the default hyper barrier. This barrier is designed to work optimally with a fixed number of threads, and has a significant setup time, so should NOT be used in situations where the number of threads in a team is varied frequently.
The two-level distributed barrier is off by default -- hyper barrier is used by default. To use this barrier, you must set all barrier patterns to use this type, because it will not work with other barrier patterns. Thus, to turn it on, the following settings are required:
KMP_FORKJOIN_BARRIER_PATTERN=dist,dist KMP_PLAIN_BARRIER_PATTERN=dist,dist KMP_REDUCTION_BARRIER_PATTERN=dist,dist
Branching factors (set with KMP_FORKJOIN_BARRIER, KMP_PLAIN_BARRIER, and KMP_REDUCTION_BARRIER) are ignored by the two-level distributed barrier.
Patch fixed for ITTNotify disabled builds and non-x86 builds
Co-authored-by: Jonathan Peyton <[email protected]> Co-authored-by: Vladislav Vinogradov <[email protected]>
Differential Revision: https://reviews.llvm.org/D103121
show more ...
|
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2 |
|
| #
681055ea |
| 04-Jun-2021 |
Joachim Protze <[email protected]> |
[OpenMP] Remove TSAN annotations from libomp
The annotations in libomp were never built by default. The annotations are also superseded by the annotations which the OMPT tool libarcher.so provides.
[OpenMP] Remove TSAN annotations from libomp
The annotations in libomp were never built by default. The annotations are also superseded by the annotations which the OMPT tool libarcher.so provides. With respect to libarcher, libomp behaves as if libarcher would be the last element of OMP_TOOL_LIBARARIES. I.e., if no other OMPT tool gets active, libarcher will check if an OpenMP application is built with TSan.
Since libarcher gets loaded by default, enabling LIBOMP_TSAN_SUPPORT would result in redundant annotations for TSan, which slightly differ in details and coverage (e.g. task dependencies are not handled well by the annotations in libomp).
This patch removes all TSan annotations from the OpenMP runtime code.
Differential Revision: https://reviews.llvm.org/D103767
show more ...
|
| #
f1b9ce27 |
| 30-Jun-2021 |
Hansang Bae <[email protected]> |
[OpenMP] Fix a few issues with hidden helper task
This patch includes the following changes to address a few issues when using hidden helper task.
- Assertion is triggered when there are inadverten
[OpenMP] Fix a few issues with hidden helper task
This patch includes the following changes to address a few issues when using hidden helper task.
- Assertion is triggered when there are inadvertent calls to hidden helper functions on non-Linux OS - Added deinit code in __kmp_internal_end_library function to fix random shutdown crashes - Moved task data access into the lock-guarded region in __kmp_push_task
Differential Revision: https://reviews.llvm.org/D105308
show more ...
|
| #
4eb90e89 |
| 29-Jun-2021 |
Johannes Doerfert <[email protected]> |
Revert "[OpenMP] Add Two-level Distributed Barrier"
This reverts commit 25073a4ecfc9b2e3cb76776185e63bfdb094cd98.
This breaks non-x86 OpenMP builds for a while now. Until a solution is ready to be
Revert "[OpenMP] Add Two-level Distributed Barrier"
This reverts commit 25073a4ecfc9b2e3cb76776185e63bfdb094cd98.
This breaks non-x86 OpenMP builds for a while now. Until a solution is ready to be upstreamed we revert the feature and unblock those builds. See: https://reviews.llvm.org/rG25073a4ecfc9b2e3cb76776185e63bfdb094cd98#1005821 and https://reviews.llvm.org/rG25073a4ecfc9b2e3cb76776185e63bfdb094cd98#1005821
The currently proposed fix (D104788) seems not to be ready yet: https://reviews.llvm.org/D104788#2841928
show more ...
|
|
Revision tags: llvmorg-12.0.1-rc1 |
|
| #
25073a4e |
| 21-May-2021 |
Terry Wilmarth <[email protected]> |
[OpenMP] Add Two-level Distributed Barrier
Two-level distributed barrier is a new experimental barrier designed for Intel hardware that has better performance in some cases than the default hyper ba
[OpenMP] Add Two-level Distributed Barrier
Two-level distributed barrier is a new experimental barrier designed for Intel hardware that has better performance in some cases than the default hyper barrier.
This barrier is designed to handle fine granularity parallelism where barriers are used frequently with little compute and memory access between barriers. There is no need to use it for codes with few barriers and large granularity compute, or memory intensive applications, as little difference will be seen between this barrier and the default hyper barrier. This barrier is designed to work optimally with a fixed number of threads, and has a significant setup time, so should NOT be used in situations where the number of threads in a team is varied frequently.
The two-level distributed barrier is off by default -- hyper barrier is used by default. To use this barrier, you must set all barrier patterns to use this type, because it will not work with other barrier patterns. Thus, to turn it on, the following settings are required:
KMP_FORKJOIN_BARRIER_PATTERN=dist,dist KMP_PLAIN_BARRIER_PATTERN=dist,dist KMP_REDUCTION_BARRIER_PATTERN=dist,dist
Branching factors (set with KMP_FORKJOIN_BARRIER, KMP_PLAIN_BARRIER, and KMP_REDUCTION_BARRIER) are ignored by the two-level distributed barrier.
Differential Revision: https://reviews.llvm.org/D103121
show more ...
|
| #
cff21556 |
| 15-Jun-2021 |
Joachim Protze <[email protected]> |
[OpenMP] Remove unused variables from libomp code
Several variables were left unused as a result of different patches removing their use.
Two variables have some use: `poll_count` is used by the KM
[OpenMP] Remove unused variables from libomp code
Several variables were left unused as a result of different patches removing their use.
Two variables have some use: `poll_count` is used by the KMP_BLOCKING macro only under certain conditions. Adding (void) to tell the compiler to ignore the unused variable.
`padding` is a dummy stack allocation with no intent to be used. Also adding (void) to make the compiler ignore the unused variable.
Differential Revision: https://reviews.llvm.org/D104303
show more ...
|
| #
92baf414 |
| 03-Jun-2021 |
Peyton, Jonathan L <[email protected]> |
[OpenMP] Fix affinity determine capable algorithm on Linux
Remove strange checks for syscall() arguments where mask is NULL. Valgrind reports these as error usages for the syscall. Instead, just che
[OpenMP] Fix affinity determine capable algorithm on Linux
Remove strange checks for syscall() arguments where mask is NULL. Valgrind reports these as error usages for the syscall. Instead, just check if CACHE_LINE bytes is long enough. If not, then search for the size. Also, by limiting the first size detection attempt to CACHE_LINE bytes, instead of 1MB, we don't use more than one cache line for the mask size. Before this patch, sometimes the returned mask size was 640 bytes (10 cache lines) because the initial call to getaffinity() was limited only by the internal kernel mask size which can be very large.
Differential Revision: https://reviews.llvm.org/D103637
show more ...
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
| #
5ebbb366 |
| 23-Mar-2021 |
Peyton, Jonathan L <[email protected]> |
[OpenMP] Allow affinity to re-detect for child processes
Current atfork() handler for child processes does not reset the affinity masks array which prevents users from setting their own affinity in
[OpenMP] Allow affinity to re-detect for child processes
Current atfork() handler for child processes does not reset the affinity masks array which prevents users from setting their own affinity in child processes.
Differential Revision: https://reviews.llvm.org/D99218
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2 |
|
| #
1611e547 |
| 20-Feb-2021 |
AndreyChurbanov <[email protected]> |
[OpenMP] libomp: cleanup some resource leaks
Close mutexattr and condattr local objects to eliminate resource leaks.
Differential Revision: https://reviews.llvm.org/D96892
|
| #
309b00a4 |
| 20-Feb-2021 |
Shilei Tian <[email protected]> |
[OpenMP][NFC] clang-format the whole openmp project
Same script as D95318. Test files are excluded.
Reviewed By: AndreyChurbanov
Differential Revision: https://reviews.llvm.org/D97088
|
|
Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init |
|
| #
9d64275a |
| 26-Jan-2021 |
Shilei Tian <[email protected]> |
[OpenMP] Added the support for hidden helper task in RTL
The basic design is to create an outer-most parallel team. It is not a regular team because it is only created when the first hidden helper t
[OpenMP] Added the support for hidden helper task in RTL
The basic design is to create an outer-most parallel team. It is not a regular team because it is only created when the first hidden helper task is encountered, and is only responsible for the execution of hidden helper tasks. We first use `pthread_create` to create a new thread, let's call it the initial and also the main thread of the hidden helper team. This initial thread then initializes a new root, just like what RTL does in initialization. After that, it directly calls `__kmpc_fork_call`. It is like the initial thread encounters a parallel region. The wrapped function for this team is, for main thread, which is the initial thread that we create via `pthread_create` on Linux, waits on a condition variable. The condition variable can only be signaled when RTL is being destroyed. For other work threads, they just do nothing. The reason that main thread needs to wait there is, in current implementation, once the main thread finishes the wrapped function of this team, it starts to free the team which is not what we want.
Two environment variables, `LIBOMP_NUM_HIDDEN_HELPER_THREADS` and `LIBOMP_USE_HIDDEN_HELPER_TASK`, are also set to configure the number of threads and enable/disable this feature. By default, the number of hidden helper threads is 8.
Here are some open issues to be discussed: 1. The main thread goes to sleeping when the initialization is finished. As Andrey mentioned, we might need it to be awaken from time to time to do some stuffs. What kind of update/check should be put here?
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D77609
show more ...
|
|
Revision tags: llvmorg-11.1.0-rc2 |
|
| #
9bf843bd |
| 18-Jan-2021 |
Shilei Tian <[email protected]> |
Revert "[OpenMP] Added the support for hidden helper task in RTL"
This reverts commit ed939f853da1f2266f00ea087f778fda88848f73.
|
| #
ed939f85 |
| 16-Jan-2021 |
Shilei Tian <[email protected]> |
[OpenMP] Added the support for hidden helper task in RTL
The basic design is to create an outer-most parallel team. It is not a regular team because it is only created when the first hidden helper t
[OpenMP] Added the support for hidden helper task in RTL
The basic design is to create an outer-most parallel team. It is not a regular team because it is only created when the first hidden helper task is encountered, and is only responsible for the execution of hidden helper tasks. We first use `pthread_create` to create a new thread, let's call it the initial and also the main thread of the hidden helper team. This initial thread then initializes a new root, just like what RTL does in initialization. After that, it directly calls `__kmpc_fork_call`. It is like the initial thread encounters a parallel region. The wrapped function for this team is, for main thread, which is the initial thread that we create via `pthread_create` on Linux, waits on a condition variable. The condition variable can only be signaled when RTL is being destroyed. For other work threads, they just do nothing. The reason that main thread needs to wait there is, in current implementation, once the main thread finishes the wrapped function of this team, it starts to free the team which is not what we want.
Two environment variables, `LIBOMP_NUM_HIDDEN_HELPER_THREADS` and `LIBOMP_USE_HIDDEN_HELPER_TASK`, are also set to configure the number of threads and enable/disable this feature. By default, the number of hidden helper threads is 8.
Here are some open issues to be discussed: 1. The main thread goes to sleeping when the initialization is finished. As Andrey mentioned, we might need it to be awaken from time to time to do some stuffs. What kind of update/check should be put here?
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D77609
show more ...
|
|
Revision tags: llvmorg-11.1.0-rc1 |
|
| #
6b316feb |
| 30-Dec-2020 |
Terry Wilmarth <[email protected]> |
[OpenMP] libomp: Handle implicit conversion warnings
This patch partially prepares the runtime source code to be built with -Wconversion, which should trigger warnings if any implicit conversions ca
[OpenMP] libomp: Handle implicit conversion warnings
This patch partially prepares the runtime source code to be built with -Wconversion, which should trigger warnings if any implicit conversions can possibly change a value. For builds done with icc or gcc, all such warnings are handled in this patch. clang gives a much longer list of warnings, particularly for sign conversions, which the other compilers don't report. The -Wconversion flag is commented into cmake files, but I'm not going to turn it on. If someone thinks it is important, and wants to fix all the clang warnings, they are welcome to.
Types of changes made here involve either improving the consistency of types used so that no conversion is needed, or else performing careful explicit conversions, when we're sure a problem won't arise.
Patch is a combination of changes by Terry Wilmarth and Johnny Peyton.
Differential Revision: https://reviews.llvm.org/D92942
show more ...
|
|
Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2 |
|
| #
171ca93c |
| 14-Dec-2020 |
Hansang Bae <[email protected]> |
[OpenMP] Initialize runtime in the forked child process
This patch enables serial initialization in the forked child process to fix unstable runtime behavior when used with Python-based AI tools.
D
[OpenMP] Initialize runtime in the forked child process
This patch enables serial initialization in the forked child process to fix unstable runtime behavior when used with Python-based AI tools.
Differential Revision: https://reviews.llvm.org/D93230
show more ...
|
| #
e0665a90 |
| 01-Dec-2020 |
Terry Wilmarth <[email protected]> |
[OpenMP] Add support for Intel's umonitor/umwait
These changes add support for Intel's umonitor/umwait usage in wait code, for architectures that support those intrinsic functions. Usage of umonitor
[OpenMP] Add support for Intel's umonitor/umwait
These changes add support for Intel's umonitor/umwait usage in wait code, for architectures that support those intrinsic functions. Usage of umonitor/umwait is off by default, but can be turned on by setting the KMP_USER_LEVEL_MWAIT environment variable.
Differential Revision: https://reviews.llvm.org/D91189
show more ...
|
| #
9615890d |
| 30-Nov-2020 |
Todd Erdner <[email protected]> |
[OpenMP] libomp: change shm name to include UID, call unregister_lib on SIGTERM
With the change to using shared memory, there were a few problems that need to be fixed. - The previous filename that
[OpenMP] libomp: change shm name to include UID, call unregister_lib on SIGTERM
With the change to using shared memory, there were a few problems that need to be fixed. - The previous filename that was used for SHM only used process id. Given that process is usually based on 16bit number, this was causing some conflicts on machines. Thus we add UID to the name to prevent this. - It appears under some conditions (SIGTERM, etc) the shared memory files were not getting cleaned up. Added a call to clean up the shm files under those conditions. For this user needs to set envirable KMP_HANDLE_SIGNALS to true.
Patch by Erdner, Todd <[email protected]>
Differential Revision: https://reviews.llvm.org/D91869
show more ...
|
|
Revision tags: llvmorg-11.0.1-rc1 |
|
| #
5644f734 |
| 20-Nov-2020 |
AndreyChurbanov <[email protected]> |
Revert "[OpenMP] Add support for Intel's umonitor/umwait"
This reverts commit 9cfad5f9c5bfd985f1bc8b0954f58013c5236e58.
|
| #
9cfad5f9 |
| 19-Nov-2020 |
AndreyChurbanov <[email protected]> |
[OpenMP] Add support for Intel's umonitor/umwait
Patch by tlwilmar (Terry Wilmarth)
Differential Revision: https://reviews.llvm.org/D91189
|
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1 |
|
| #
d28f8672 |
| 28-Jul-2020 |
Jinsong Ji <[email protected]> |
Re-land "[PowerPC] Remove QPX/A2Q BGQ/BGP CNK support"
This reverts commit bf544fa1c3cb80f24d85e84559fb11193846259f.
Fixed the typo in PPCInstrInfo.cpp.
|
| #
bf544fa1 |
| 27-Jul-2020 |
Jinsong Ji <[email protected]> |
Revert "[PowerPC] Remove QPX/A2Q BGQ/BGP CNK support"
This reverts commit adffce71538e219aab4eeb024819baa7687262ff.
This is breaking test-suite, revert while investigation.
|