Introduce common infrastructure for runtimes that determines compiler
resource path locations. These variables introduced are:
* RUNTIMES_OUTPUT_RESOURCE_DIR
* RUNTIMES_INSTALL_RESOURCE_PATH
That contain the location for the compiler resource path (typically
`lib/clang/<version>`) in the build tree and the install tree (the
latter relative to CMAKE_INSTALL_PREFIX).
Additionally, define
* RUNTIMES_OUTPUT_RESOURCE_LIB_DIR
* RUNTIMES_INSTALL_RESOURCE_LIB_PATH
as for the location of clang/flang version-locked libraries (typically
`lib${LLVM_LIBDIR_SUFFIX}/<targer-triple>`, but also depends on `APPLE`
and `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR`). This code is moved from
flang-rt and initially becomes its only user.
Refactored out of #171610 as requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2687382481).
Extracted `get_runtimes_target_libdir_common` from compiler-rt as
requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2689565634).
Added TODO comments to all runtimes as requested
[here](https://github.com/llvm/llvm-project/pull/171610#issuecomment-3789598635).
This patch allows building libomp.dll and libomp.lib as Arm64X binaries
containing both arm64 and arm64ec code and useable from applications
compiled for both architectures.
This patch adds arm64ec support to libomp.
Note that this support isn't entirely usable on Windows hosts as libomp
requires LLVM_PER_TARGET_RUNTIME_DIR=On for to work correctly when
multiple runtimes are built, which is unsupported on Windows. A
following patch will add arm64x support to the build to rectify this.
This change adds implementation for named barriers for SPIRV backend.
Since there is no built in API/intrinsics for named barrier in SPIRV,
the implementation loosely follows implementation for AMD
With the standalone and project builds removed,
`OPENMP_TEST_COMPILER_HAS_OMP_H`/`config.test_compiler_has_omp_h` is set
to constant 1, which causes the `config.omp_header_directory` search
path NOT to be added to `%flags-use-compiler-omp-h`, causing the system
`omp.h` used, or the only test actually using it
(`omp50_taskdep_depobj.c`) failing if that one is not available.
The intention of `OPENMP_TEST_COMPILER_HAS_OMP_H` was to use gcc's
`omp.h` which declares `omp_depend_t` differently than our `omp.h`
(https://reviews.llvm.org/D108790). Using `OPENMP_TEST_C_COMPILER=gcc`
was used to test libomp's GOMP compatibility layer, but testing it is
currently unmaintained and has no buildbot (60 failing tests out of 389
with gcc-13, not including OMPD and OMPT). If updating testing for GOMP,
then gcc's own `omp.h` must be used for all tests: using the GOMP ABI
requires using GOMP's `omp.h`.
Closes: #187879
Summary:
Right now the CMake does not follow the pattern other runtime projects
use. All this does is use the standard subdir to place libraries in a
unique location. This allows, for example, users to configure a debug
version of openmp / offload within the same CMake invocation.
---------
Co-authored-by: Michael Kruse <github@meinersbur.de>
The genericStateMachine call uses synchronize::thread wich is expected
to be implemented using a workgroup level barrier.
Currently as in some other architectures where if threads in the same
warp as the main thread reach the barrier may cause a race condition
there's a condition that makes some threads not enter the state machine.
But in Intel GPUs all threads must reach the barrier for it to be
completed, otherwise the threads in the state machine never make
progress.
This PR moves the condition into an architecture-dependent config so it
can work correctly for both kinds of hardware.
Summary:
The changes in https://www.github.com/llvm/llvm-project/pull/185552
allowed us to
start building the standard `libclang_rt.profile.a` for GPU targets.
This PR expands this by adding an optimized GPU routine for counter
increment and removing the special-case handling of these functions in
the OpenMP runtime.
Vast majority of these functions are boilerplate, but we should be able
to do more interesting things with this in the future, like value or
memory profiling.
While `omp-tools.h` already includes the `ompt_record_error_t` struct,
the corresponding union entry was missing from `ompt_record_ompt_t`.
This commit adds the missing entry.
Note that this does not enable any functionality for device tracing
records.
This only aligns the struct with OpenMP v5.1 and newer. OpenMP v5.0 did
not contain the `error` directive.
CC: @jprotze
Signed-off-by: Jan André Reuter <j.reuter@fz-juelich.de>
Translate affinity entries to LLVMIR by passing affinity information to
createTask (__kmpc_omp_reg_task_with_affinity is created inside
PostOutlineCB).
3/3 in stack for implementing affinity clause with iterator modifier
1/3 #182218
2/3 #182222
3/3 #182223
This commit removes the `LIBOMPTARGET_SHARED_MEMORY_SIZE` envar and
outputs a runtime warning if it is defined. Access to dynamic shared memory
should be obtained through the `dyn_groupprivate` clause (OpenMP 6.1) or
the launch arguments in liboffload kernel launch.
Link against Threads using PRIVATE scope, instead of PUBLIC.
Reason: it imposes a transitive dependency on library users.
If Threads could not be found this could cause a link error.
The issue would manifest, if omptest is used via find_package.
Addresses issues with previous PR
https://github.com/llvm/llvm-project/pull/185930
Removed link against `Threads`.
Reason: it is potentially problematic and optional.
The issue would manifest, if `omptest` is used via `find_package`.
But `Threads` might not be found and cause a link error.
When using
set(var "Example")
if (${var})
CMake will first resolve the if-argument to
if (Example)
And what then happens depends on the existance of a variable with the
name "Example":
1. If instead of "Example", a truth constant is used ("TRUE", "FALSE",
"ON", "OFF", "", "-NOTFOUND" ...), it is prioritized
(https://cmake.org/cmake/help/latest/command/if.html#constant)
2. If a variable with the name "Example" exists: Use the truthiness of
its content
(https://cmake.org/cmake/help/latest/command/if.html#variable)
3. Otherwise, it is false-y
That is, the the result of the conditional does not only depend on the
content of `var`, but also some other variable. This is usually
unintended and leads to problems such as addressed with #154537. The
only case where this is intended is when passing an expression to be
evaluated such as with `pythonize_bool`, `append_if` and
`libomp_append`. In all other cases, using `${var}` without quotes is a
pattern to be avoided.
Remark:
If `${var}` is not one of the values considered a [truthiness
constant](https://cmake.org/cmake/help/latest/command/if.html#constant),
the result of `if (var)` and `if ("${var}")` is different:
* `if (var)` is true-ish
(https://cmake.org/cmake/help/latest/command/if.html#variable)
* `if ("Example")` and therefore `if ("${var}")` are false-y
(https://cmake.org/cmake/help/latest/command/if.html#string)
In this PR I am preferring `if (var)` over `if ("${var}")` because has
less clutter, resembles Python's behaviour, and problably what most
users are expecting, even though `if (${var})` in most cases would
evaluate to false-y because a variable does not exist. This ambiguity
does not exist for STREQUAL and MATCHES.
#183269 tried to fix the test, but the test can still randomly fail. The
OpenMP spec does not prevent the runtime to chose a smaller team size
than returned from omp_max_threads() for the second parallel region.
Using a larger value than `omp_max_threads()` in a `num_threads` clause
is valid OpenMP code. With a correct OpenMP implementation, the
team-size of the second parallel region must still be smaller or equal
the value returned from `omp_max_threads()`.
This test assumes that the number of available threads is not 3,
otherwise `#pragma omp parallel` and `#pragma omp parallel
num_thread(3)` are naturally going to do the same thing.
Instead use `omp_get_max_threads() - 1` as the number of threads in the
initial `omp parallel num_thread(N)` and then check that the number of
threads does not match the value in the later `omp parallel`.
Having a build tree with "not" and "FileCheck" is still required, but if
Clang/Flang isn't configured in that build, run the tests with the same
compiler CMake uses. This is how testing worked in the standalone build
configurations that now have been removed.
This reapplies #149878
Remove all the CMake code for openmp standalone builds. Standalone
builds have been superseded by the runtimes default build (also
sometimes called the standalone runtimes build). The runtimes default
build can be thought of a standalone build with the standalone
boilerplate contained in <llvm-project>/runtimes/CMakeLists.txt. There
is no need for each runtime to contain the same boilerplate code again.
Builds still using the standalone build via
```sh
cmake -S <llvm-project>/openmp ...
```
can switch over to the runtimes default build using
```sh
cmake -S <llvm-project>/runtimes -DLLVM_ENABLE_RUNTIMES=openmp ...
```
Options that were valid for the standalone build are also valid for
default runtimes build, unless handled only in `if
(OPENMP_STANDALONE_BUILD)` regions.
The existence of both, standalone builds and runtime default builds,
easily leads to confusion such as fixed in #149871. A non-standalone
build does not mean that it is built as part of a bootstrapping-build of
LLVM inside the `runtimes/runtimes-bins` directory, nor does it mean
that the compiler is necessarily Clang. Some of the remaining code may
have been written with that assumption. However, the purpose of this
patch is to only remove the standalone build functionality.
Remove all the CMake code for openmp standalone builds. Standalone
builds have been superseded by the runtimes default build (also
sometimes called the standalone runtimes build). The runtimes default
build can be thought of a standalone build with the standalone
boilerplate contained in <llvm-project>/runtimes/CMakeLists.txt. There
is no need for each runtime to contain the same boilerplate code again.
Builds still using the standalone build via
```sh
cmake -S <llvm-project>/openmp ...
```
can switch over to the runtimes default build using
```sh
cmake -S <llvm-project>/runtimes -DLLVM_ENABLE_RUNTIMES=openmp ...
```
Options that were valid for the standalone build are also valid for
default runtimes build, unless handled only in
`if (OPENMP_STANDALONE_BUILD)` regions.
The existence of both, standalone builds and runtime default builds,
easily leads to confusion such as fixed in #149871. A non-standalone
build does not mean that it is built as part of a bootstrapping-build of
LLVM inside the `runtimes/runtimes-bins` directory, nor does it mean
that the compiler is necessarily Clang. Some of the remaining code may
have been written with that assumption. However, the purpose of this
patch is to only remove the standalone build functionality.
This patch is a follow-up from #161213 and adds the omp.fuse loop
transformation for the OpenMP dialect. Used for lowering a `!$omp fuse`
in Flang.
Added Lowering and end2end tests.
Summary:
Closing ports was previously done manually, This makes the protocol more
error prone as unclosed ports will leak and eventually the locks will
run out. I believe the original fear was that the RAII portion would
negatively impact code generation but I have not noticed anything
significant.
These tests were converted from Perl to Python in #95307, so there is no
perl dependency here anymore. (I omitted an explicit mention of Python
here, as that's a general dependency anyway.)
The AMDGPU check was added in
https://github.com/llvm/llvm-project/pull/123670 where the reasoning
seems to be that the NVIDIA SDK will provide `vprintf` for the NVPTX
case and AMDGPU was the only other supported target at the time.
SPIR-V also needs this stubbed out, so just check that it's not NVPTX.
Signed-off-by: Nick Sarnie <nick.sarnie@intel.com>
Reapply #152189 and #174963 which were reverted because it broke
publish-sphinx-docs and publish-doxygen-docs.
The build mode has been deprecated in #136314 and was supposed to be
removed in the LLVM 21 release (#136314).
OpenMP currently supports 4 build modes:
* `cmake <llvm-project>/llvm -DLLVM_ENABLE_PROJECTS=openmp`
* `cmake <llvm-project>/llvm -DLLVM_ENABLE_RUNTIMES=openmp` (bootstrapping build)
* `cmake <llvm-project>/openmp` (standalone build)
* `cmake <llvm-project>/runtimes -DLLVM_ENABLE_RUNTIMES=openmp` (runtimes default/standalone build)
Each build mode increased the maintanance overhead since all build modes
must continue working and user confusion when there do not (see #151117,
#174126, #154117, ...). Let's finally remove it.
Go into more detail on the two non-legacy build modes.
I decided use create a dedicated document documention the build process.
`index.rst` only keeps the "Getting Started" part. `README.rst` is
vastly outdated with the still valid parts integrated into the new
documentation. `SupportAndFAQ.rst` is unstructured and keeps only the
non-building parts.
The the new building document is written in Meltdown, following the
decision from LLVM.
This PR adds configuration to build DeviceRTL with SPIRV backend. It is
primarily used for level-zero plugin for Intel GPUs
---------
Co-authored-by: Joseph Huber <huberjn@outlook.com>
Summary:
These shouldn't be so different after we moved away from variants. It's
much simpler to define this in-line with a single preprocessor
definition. This should be equivalent less a few unnecessary function
definitions with the advantage that SPIR-V now has less work to do.
Summary:
The `__scoped_atomic` builtins are supposed to match the standard
GNU-flavored `__atomic` builtins. We added a scoped builtin without a
corresponding standard one before the fork so this should be added in
the release candidate. These were originally added in
https://github.com/llvm/llvm-project/pull/168666
Also, the name `uinc_wrap` does not follow the naming convention. The
GNU atomics use `fetch_xyz` to indicate that the builtin returns the
previous location's value as part of the RMW operation, which these do.
This PR renames it and its uses.
Reapply #152189 which was reverted because it broke publish-sphinx-docs.
The build mode has been deprecated in #136314. According to the
deprecation message, it was supposed to be removed in the LLVM 21
release. Each build mode increased the maintanance overhead when
failing, such as in #151117.
Corrected various spelling mistakes such as 'occurred', 'receiver',
'initialized', 'length', and others in comments, variable names,
function names, and documentation throughout the project. These
changes improve code readability and maintain consistency in naming
and documentation.
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
