Redo after revert by hans. The wrong include in one test is fixed.
Make sure that OMPT is enabled in runtime entry points that access internals
of the runtime. Else, return an appropiate value indicating an error or that
the data is not available.
Patch provided by @sconvent
Reviewers: jlpeyton, omalyshe, hbae, Hahnfeld, joachim.protze
Reviewed By: joachim.protze
Tags: #openmp, #ompt
Differential Revision: https://reviews.llvm.org/D47717
llvm-svn: 352611
This fixes most references to the paths:
llvm.org/svn/
llvm.org/git/
llvm.org/viewvc/
github.com/llvm-mirror/
github.com/llvm-project/
reviews.llvm.org/diffusion/
to instead point to https://github.com/llvm/llvm-project.
This is *not* a trivial substitution, because additionally, all the
checkout instructions had to be migrated to instruct users on how to
use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of
checking out various projects into various subdirectories.
I've attempted to not change any scripts here, only documentation. The
scripts will have to be addressed separately.
Additionally, I've deleted one document which appeared to be outdated
and unneeded:
lldb/docs/building-with-debug-llvm.txt
Differential Revision: https://reviews.llvm.org/D57330
llvm-svn: 352514
As the codebase is now under the Apache 2.0 license with LLVM
Exceptions, and all Arm's contributions, past or future, are under that
new license, this Arm specific words in LICENSE.txt are no longer
needed.
llvm-svn: 352377
all missed!
Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.
llvm-svn: 351731
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.
Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.
I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.
This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.
Differential Revision: https://reviews.llvm.org/D56897
llvm-svn: 351631
and also the follow-up r351315.
The new test is failing on the buildbots.
> Make sure that OMPT is enabled in runtime entry points that access internals
> of the runtime. Else, return an appropiate value indicating an error or that
> the data is not available.
>
> Patch provided by @sconvent
>
> Reviewers: jlpeyton, omalyshe, hbae, Hahnfeld, joachim.protze
>
> Reviewed By: joachim.protze
>
> Tags: #openmp, #ompt
>
> Differential Revision: https://reviews.llvm.org/D47717
llvm-svn: 351431
Add omp_pause_resource and omp_pause_resource_all API and enum, plus stub for
internal implementation. Implemented callable helper function to do local pause,
and added basic functionality for hard and soft pause.
Patch by Terry Wilmarth
Differential Revision: https://reviews.llvm.org/D55078
llvm-svn: 351372
The compiler warns about an unused variable/statement:
runtime/src/kmp_affinity.cpp:4958:18: warning: statement has no effect [-Wunused-value]
KA_TRACE(1000, ; {
^
runtime/src/kmp_debug.h:84:24: note: in definition of macro 'KA_TRACE'
__kmp_debug_printf x; \
^
Instead of the unused reference to this function, this patch now calls the function
with an empty string. The call to this function should have no effect.
Patch provided by joachim.protze
Reviewers: jlpeyton, hbae, AndreyChurbanov
Reviewed By: AndreyChurbanov
Tags: #openmp, #ompt
Differential Revision: https://reviews.llvm.org/D56775
llvm-svn: 351323
Make sure that OMPT is enabled in runtime entry points that access internals
of the runtime. Else, return an appropiate value indicating an error or that
the data is not available.
Patch provided by @sconvent
Reviewers: jlpeyton, omalyshe, hbae, Hahnfeld, joachim.protze
Reviewed By: joachim.protze
Tags: #openmp, #ompt
Differential Revision: https://reviews.llvm.org/D47717
llvm-svn: 351311
Using proc_bind clause on a nested #pragma omp parallel region
with KMP_AFFINITY set causes an assertion error. This assertion occurs because
the place-partition-var is not properly initialized in the nested master threads.
Trying to get an intuitive result with KMP_AFFINITY + proc_bind is difficult
because of how the KMP_AFFINITY gtid-to-place mapping occurs. This
patch creates an initial place list no matter what affinity mechanism is used.
For KMP_AFFINITY, the place-partition-var is initialized to all the places.
Differential Revision: https://reviews.llvm.org/D55795
llvm-svn: 351227
This change fixes the sanity issue reported in Bug 40042.
Lock function definitions for the three lock kinds were added
to disambiguate calls to the lock functions done directly and indirectly.
Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=40042
Patch by Hansang Bae
Differential Revision: https://reviews.llvm.org/D56103
llvm-svn: 351224
Fix ninja build detect test compiler failed under windows.
Patch by Peiyuan Song
Differential Revision: https://reviews.llvm.org/D53479
llvm-svn: 351223
Make __ompt_implicit_task_end a static function and remove the inline part. Remove
pId variable that is unused. This fixes small regression in SPEC kdtree benchmark.
Also reformat some of __ompt_implicit_task_end.
Differential Revision: https://reviews.llvm.org/D55788
llvm-svn: 351221
The omp-tools.h file is generated from the OpenMP spec to ensure that the interface
is implemented as specified.
The other changes are necessary to update the interface implementation to the
final version as published in 5.0.
The omp-tools.h header was previously called ompt.h, currently a copy under this name
is installed for legacy tools.
Patch partially perpared by @sconvent
Reviewers: AndreyChurbanov, hbae, Hahnfeld
Reviewed By: hbae
Tags: #openmp, #ompt
Differential Revision: https://reviews.llvm.org/D55579
llvm-svn: 351197
Summary:
Two things:
1. Those two variables had the wrong sigdness, which was resulting in "sign mismatch in comparison" warning.
2. The whole `kmp_debugger.cpp` wasn't being built, or rather, it was being built as-if `USE_DEBUGGER` was off,
thus, nothing provided the definition of `__kmp_omp_debug_struct_info`, `__kmp_debugging`.
Makes sense, because `USE_DEBUGGER` is set in `kmp_config.h`, which is not included explicitly.
It is included by `kmp.h`, but that one is only included inside of the `#if USE_DEBUGGER` block..
I *think* this is the only source file with this issue,
everything else seem to `#include` either `kmp.h` or `kmp_config.h`.
The alternative solution would be to add `add_compile_options(-include kmp_config.h)` in CMake.
I did verify that `__kmp_omp_debug_struct_info` becomes available with this patch.
Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=38612 | PR38612 ]].
Reviewers: AndreyChurbanov, jlpeyton, Hahnfeld
Reviewed By: jlpeyton
Subscribers: guansong, jfb, openmp-commits
Tags: #openmp
Differential Revision: https://reviews.llvm.org/D55783
llvm-svn: 351019
Summary: Replace existing infrastructure for tracking parallel level using global memory with a per-team shared memory variable. This minimizes the impact of the overhead of tracking the parallel level for non-nested cases.
Reviewers: ABataev, caomhin
Reviewed By: ABataev
Subscribers: guansong, openmp-commits
Differential Revision: https://reviews.llvm.org/D55773
llvm-svn: 350747
Summary:
Previous implementation may cause the runtime crash when the number of
teams is > 1024. Patch fixes this problem + reduces number of the atomic
operations by 32 times.
Reviewers: grokos, gtbercea, kkwli0
Subscribers: guansong, jfb, openmp-commits, caomhin
Differential Revision: https://reviews.llvm.org/D56332
llvm-svn: 350524
Summary:
Reduced number of the used register + improved performance propagating
the information about current execution/data sharing mode directly from
the compiler, where it is possible.
In some cases, it requires new/reworked interfaces of the runtime
external functions. Old functions are marked as deprecated.
Reviewers: grokos, gtbercea, kkwli0
Subscribers: guansong, jfb, openmp-commits, caomhin
Differential Revision: https://reviews.llvm.org/D56278
llvm-svn: 350405
The OpenMP runtime's cmake scripts do not correctly locate the
libdevice that the Debian/Ubuntu package nvidia-cuda-toolkit currently
includes, at least on my Ubuntu 18.04.1 installation. This patch
fixes that for me.
This problem was discussed at length in D55269. D40453 added a
similar adjustment in clang, but reviewers of D55269 concluded that,
for the OpenMP runtime, the right place to address this problem is in
cmake's CUDA support. However, it was also suggested we could add a
workaround to OpenMP's cmake scripts now. This patch contains such a
workaround, which I've tried to design so that it will have no harmful
effect if cmake improves in the future.
nvidia-cuda-toolkit also needs improvements because its intended
monolithic CUDA tree shim, /usr/lib/cuda, has many empty directories,
such as bin. I reported that at:
<https://bugs.launchpad.net/ubuntu/+source/nvidia-cuda-toolkit/+bug/1808999>
Reviewed By: grokos
Differential Revision: https://reviews.llvm.org/D55588
llvm-svn: 350377
Add omp_get_device_num() function for 5.0 which returns the number of the
device the current thread is running on. Currently, we are leaving it to the
compiler to handle this properly if it is called inside target.
Also, did some cleanup and updating of duplicate device API functions (in both
libomp and libomptarget) to make them into weak functions that check for the
symbol from libomptarget, and will call the version in libomptarget if it is
present. If any additional device API functions are implemented also in
libomptarget in the future, we should add the dlsym calls to the host functions.
Also, if the omp_target_* functions are to be implemented for the host (this has
been requested), they should attempt to call the libomptarget versions as well.
Patch by Terry Wilmarth
Differential Revision: https://reviews.llvm.org/D55578
llvm-svn: 350352
Summary:
One of the LLVM optimizations, split critical edges, also clones tail
instructions. This is a dangerous operation for __syncthreads()
functions and this transformation leads to undefined behavior or
incorrect results. Patch fixes this problem by replacing __syncthreads()
function with the assembler instruction, which cost is too high and
wich cannot be copied.
Reviewers: grokos, gtbercea, kkwli0
Subscribers: guansong, openmp-commits, caomhin
Differential Revision: https://reviews.llvm.org/D56274
llvm-svn: 350333
Summary:
Avoid using of the atomic loop to wait for the completion of the
data-sharing interface initialization, use __shfl_sync instead for the
communication within the warp to signal other threads in the warp about
completion of the initialization.
Reviewers: gtbercea, kkwli0, grokos
Subscribers: guansong, jfb, caomhin, openmp-commits
Differential Revision: https://reviews.llvm.org/D56100
llvm-svn: 350129
Summary:
At high optimization level asserts lead to some unexpected results
because of auto-inserted unreachable instructions. This outlining
prevents some of such dangerous optimizations and leads to better
stability.
Reviewers: gtbercea, kkwli0, grokos
Subscribers: guansong, caomhin, openmp-commits
Differential Revision: https://reviews.llvm.org/D56101
llvm-svn: 350128
Fix the newly-added tests to use %python substitution in order to use
the correct path to Python interpreter. Otherwise, they fail on NetBSD
where there is no 'python', just 'pythonX.Y'.
Differential Revision: https://reviews.llvm.org/D56048
llvm-svn: 350001
XFAIL two tests that fail on PowerPC LE Linux due
to the change of default from PIC to no-PIC on that
platform.
A Bug has been opened for this:
https://bugs.llvm.org/show_bug.cgi?id=40082
The tests are:
runtime/test/ompt/misc/control_tool.c
runtime/test/ompt/synchronization/taskwait.c
llvm-svn: 349512
This patch updates the implementation of the ompt_frame_t, ompt_wait_id_t
and ompt_state_t. The final version of the OpenMP 5.0 spec added the "t"
for these types.
Furthermore the structure for ompt_frame_t changed and allows to specify
that the reenter frame belongs to the runtime.
Patch partially prepared by Simon Convent
Reviewers: hbae
llvm-svn: 349458
Summary:
I have discovered this because i wanted to experiment with
building static libomp (with openmp-4.0 support only)
for debugging purposes.
There are three kinds of problems here:
1. `__kmp_compare_and_store_acq()` simply does not exist.
It was added in D47903 by @jlpeyton.
I'm guessing `__kmp_atomic_compare_store_acq()` was meant.
2. In `__kmp_is_ticket_lock_initialized()`,
`lck->lk.initialized` is `std::atomic<bool>`,
while `lck` is `kmp_ticket_lock_t *`.
Naturally, they can't be equality-compared.
Either, it should return the value read from `lck->lk.initialized`,
or do what `__kmp_is_queuing_lock_initialized()` does,
compare the passed pointer with the field in the struct
pointed by the pointer. I think the latter is correct-er choice here.
3. Tests were not versioned.
They assume that `LIBOMP_OMP_VERSION` is at the latest version.
This does not touch LIBOMP_OMP_VERSION=30. That is still broken.
Reviewers: jlpeyton, Hahnfeld, AndreyChurbanov
Reviewed By: AndreyChurbanov
Subscribers: guansong, jfb, openmp-commits, jlpeyton
Tags: #openmp
Differential Revision: https://reviews.llvm.org/D55496
llvm-svn: 349260
The value returned by __kmp_now_nsec() can overflow 32-bit values causing
incorrect values to be returned. The overflow can end up causing a divide
by zero error because in __kmp_initialize_system_tick(), the value
(__kmp_now_nsec() - nsec) can end up being much larger than the numerator:
1e6 * (delay + (now - goal))
during a pathological timing where the current time calculated is much larger
than nsec. When this happens, the value of __kmp_ticks_per_msec is set to zero
which is then used as the denominator in the KMP_NOW_MSEC() macro leading to
the divide by zero error.
Differential Revision: https://reviews.llvm.org/D55300
llvm-svn: 349090
This patch adds the affinity format functionality introduced in OpenMP 5.0.
This patch adds: Two new environment variables:
OMP_DISPLAY_AFFINITY=TRUE|FALSE
OMP_AFFINITY_FORMAT=<string>
and Four new API:
1) omp_set_affinity_format()
2) omp_get_affinity_format()
3) omp_display_affinity()
4) omp_capture_affinity()
The affinity format functionality has two ICV's associated with it:
affinity-display-var (bool) and affinity-format-var (string).
The affinity-display-var enables/disables the functionality through the
envirable OMP_DISPLAY_AFFINITY. The affinity-format-var is a formatted
string with the special field types beginning with a '%' character
similar to printf
For example, the affinity-format-var could be:
"OMP: host:%H pid:%P OStid:%i num_threads:%N thread_num:%n affinity:{%A}"
The affinity-format-var is displayed by every thread implicitly at the beginning
of a parallel region when any thread's affinity has changed (including a brand
new thread being spawned), or explicitly using the omp_display_affinity() API.
The omp_capture_affinity() function can capture the affinity-format-var in a
char buffer. And omp_set|get_affinity_format() allow the user to set|get the
affinity-format-var explicitly at runtime. omp_capture_affinity() and
omp_get_affinity_format() both return the number of characters needed to hold
the entire string it tried to make (not including NULL character). If not
enough buffer space is available,
both these functions truncate their output.
Differential Revision: https://reviews.llvm.org/D55148
llvm-svn: 349089
Disable KMP_HAVE_QUAD when building via gcc on NetBSD system,
as the build fails due to unimplemented builtins:
.../kmp_atomic.cpp.o: In function `__kmpc_atomic_cmplx16_mul':
.../kmp_atomic.cpp:1332: undefined reference to `__multc3'
.../kmp_atomic.cpp.o: In function `__kmpc_atomic_cmplx16_div':
.../kmp_atomic.cpp:1334: undefined reference to `__divtc3'
...
Differential Revision: https://reviews.llvm.org/D55478
llvm-svn: 348886
Switch NetBSD from reading /proc (which is broken) to getloadavg()
(which is already used by Darwin). NetBSD discourages using procfs
in favor of system API calls.
Differential Revision: https://reviews.llvm.org/D55486
llvm-svn: 348885
Summary:
Use the sysctl(3) function to check whether an address is mapped
into the address space.
Reviewers: mgorny, joerg, #openmp
Reviewed By: mgorny
Subscribers: openmp-commits
Tags: #openmp
Differential Revision: https://reviews.llvm.org/D55549
llvm-svn: 348874
Summary: _lwp_self() returns current Thread Id in a numeric version on NetBSD.
Reviewers: joerg, mgorny, #openmp
Reviewed By: mgorny
Subscribers: llvm-commits, openmp-commits, #openmp
Tags: #openmp
Differential Revision: https://reviews.llvm.org/D55497
llvm-svn: 348873
Increase the range for omp_get_wtick() test to allow for 0.01
(from <0.01). This is needed for NetBSD where it returns exactly that
value due to CLOCKS_PER_SEC being 100. This should not cause
a significant difference from e.g. FreeBSD where it is 128,
and especially from Linux where CLOCKS_PER_SEC is apparently meaningless
and sysconf(_SC_CLK_TCK) gives 100 as well.
Differential Revision: https://reviews.llvm.org/D55493
llvm-svn: 348857
Joachim Protze