<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/llvm.git/openmp/runtime/src/z_Linux_util.cpp, branch EmptyLineAfterFunctionDefinition</title>
<subtitle>github.com: llvm/llvm-project.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/'/>
<entry>
<title>[OpenMP][libomp] Add support for offline CPUs in Linux</title>
<updated>2021-11-17T22:28:01+00:00</updated>
<author>
<name>Peyton, Jonathan L</name>
<email>jonathan.l.peyton@intel.com</email>
</author>
<published>2021-10-21T21:43:54+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=1dd797168e9f8cb592c254c642f196dab3447092'/>
<id>1dd797168e9f8cb592c254c642f196dab3447092</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>[OpenMP][libomp][NFC] Remove non-ASCII apostrophe in comment</title>
<updated>2021-11-17T20:46:40+00:00</updated>
<author>
<name>Jonathan Peyton</name>
<email>jonathan.l.peyton@intel.com</email>
</author>
<published>2021-11-17T20:46:23+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=c46becf500df2a7fb4b4fce16178a036c344315a'/>
<id>c46becf500df2a7fb4b4fce16178a036c344315a</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[OpenMP][NFC] libomp: silence warnings on unused variables.</title>
<updated>2021-07-30T14:04:42+00:00</updated>
<author>
<name>AndreyChurbanov</name>
<email>andrey.churbanov@intel.com</email>
</author>
<published>2021-07-30T14:04:42+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=8b81524c6dd27b8dd7a36d525e5569cdf8d5e188'/>
<id>8b81524c6dd27b8dd7a36d525e5569cdf8d5e188</id>
<content type='text'>
Put declarations/definitions of unused variables under corresponding macros
to silence clang build warnings.

Differential Revision: https://reviews.llvm.org/D106608
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Put declarations/definitions of unused variables under corresponding macros
to silence clang build warnings.

Differential Revision: https://reviews.llvm.org/D106608
</pre>
</div>
</content>
</entry>
<entry>
<title>[OpenMP] libomp: Add new experimental barrier: two-level distributed barrier</title>
<updated>2021-07-29T19:09:26+00:00</updated>
<author>
<name>Terry Wilmarth</name>
<email>terry.l.wilmarth@intel.com</email>
</author>
<published>2021-07-15T15:28:47+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=d8e4cb912180ce0a35d31b616e6f4c0c3d64abb7'/>
<id>d8e4cb912180ce0a35d31b616e6f4c0c3d64abb7</id>
<content type='text'>
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 &lt;jonathan.l.peyton@intel.com&gt;
Co-authored-by: Vladislav Vinogradov &lt;vlad.vinogradov@intel.com&gt;

Differential Revision: https://reviews.llvm.org/D103121
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;jonathan.l.peyton@intel.com&gt;
Co-authored-by: Vladislav Vinogradov &lt;vlad.vinogradov@intel.com&gt;

Differential Revision: https://reviews.llvm.org/D103121
</pre>
</div>
</content>
</entry>
<entry>
<title>[OpenMP] Remove TSAN annotations from libomp</title>
<updated>2021-07-12T16:49:11+00:00</updated>
<author>
<name>Joachim Protze</name>
<email>protze@itc.rwth-aachen.de</email>
</author>
<published>2021-06-04T12:05:05+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=681055ea694b1de21a52b319329e5d4f9b1b807d'/>
<id>681055ea694b1de21a52b319329e5d4f9b1b807d</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>[OpenMP] Fix a few issues with hidden helper task</title>
<updated>2021-07-01T22:10:32+00:00</updated>
<author>
<name>Hansang Bae</name>
<email>hansang.bae@intel.com</email>
</author>
<published>2021-06-30T19:01:04+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=f1b9ce2736d826df2ff4cbd67116864f0856334f'/>
<id>f1b9ce2736d826df2ff4cbd67116864f0856334f</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[OpenMP] Add Two-level Distributed Barrier"</title>
<updated>2021-06-29T14:38:27+00:00</updated>
<author>
<name>Johannes Doerfert</name>
<email>johannes@jdoerfert.de</email>
</author>
<published>2021-06-29T14:34:53+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=4eb90e893f82314def571f7129dfd88bd098208b'/>
<id>4eb90e893f82314def571f7129dfd88bd098208b</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>[OpenMP] Add Two-level Distributed Barrier</title>
<updated>2021-06-16T20:34:55+00:00</updated>
<author>
<name>Terry Wilmarth</name>
<email>terry.l.wilmarth@intel.com</email>
</author>
<published>2021-05-21T22:06:09+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=25073a4ecfc9b2e3cb76776185e63bfdb094cd98'/>
<id>25073a4ecfc9b2e3cb76776185e63bfdb094cd98</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>[OpenMP] Remove unused variables from libomp code</title>
<updated>2021-06-16T07:33:46+00:00</updated>
<author>
<name>Joachim Protze</name>
<email>protze@itc.rwth-aachen.de</email>
</author>
<published>2021-06-15T07:17:26+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=cff215565e9351511d805f72e62803718be6aaa4'/>
<id>cff215565e9351511d805f72e62803718be6aaa4</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>[OpenMP] Fix affinity determine capable algorithm on Linux</title>
<updated>2021-06-15T21:21:30+00:00</updated>
<author>
<name>Peyton, Jonathan L</name>
<email>jonathan.l.peyton@intel.com</email>
</author>
<published>2021-06-03T17:49:04+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=92baf414dbfb31d7d69bea56a0ce982d2b737268'/>
<id>92baf414dbfb31d7d69bea56a0ce982d2b737268</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
</feed>
