Summary:
This is used in the GPU portion of the build, but really shouldn't be.
Most of these helpers were only used by the GPU portion, which has much
nicer builtins available in new clang. Using these in the main offload
build is broken on Windows and not available on older compilers, so we
split. Also means one less header we share.
The alignment helpers are trivially replaced by an LLVM utility, the
only thing that remains are the pointer arithmetic functions. There's no
conveient place to put these so I just let them stay.
The OpenMP specification offers different ways for identifying the host
device. While users of the OpenMP API can use `omp_get_initial_device()`
or the constant `omp_initial_device` (available since OpenMP v5.2), a
tool needs to rely on the `initial_device_num` passed by the OpenMP
runtime during the `initialize` callback.
In #134451, it was discovered that the `initial_device_num` passed is
always `0`, regardless of any device are available for offload
execution. For host-only OpenMP code, this matches the result of
`omp_get_num_devices()`, and is a valid result. In the case of devices
being available though, this passed identifier is incorrect. While
`libomp` calls `omp_get_num_devices()`, `libomptarget` has not fully
initialized its PluginManager at that point, hence returning no
available devices. Tools relying on `initial_device_num` might therefore
incorrectly assume host-side execution when some code runs on a device.
Since the `ompt_get_num_devices()` entry point is also not fully
implemented, tools currently need to do on-the-fly handling for the host
device.
To make handling easier, consistently use the `omp_initial_device`
identifier as the `initial_device_num` and for all device callbacks.
This does not rely on knowing the number of available devices during
OMPT initialization in the runtime and ensures a consistent value for
tools to handle.
Closes#134451
Signed-off-by: Jan André Reuter <j.reuter@fz-juelich.de>
When dladdr() fails, dl_info is left uninitialized. The code printed the
error but then fell through to unconditionally call
strrchr(dl_info.dli_fname, '/'), accessing an uninitialized pointer --
typically NULL on the stack -- causing a SIGSEGV.
Fix by turning the second 'if' into 'else if', so the path-extraction
block is only reached when dladdr() succeeded and dl_info is valid.
Assisted-by: Claude Sonnet 4.6
As per OpenMP 5.2/6.0 the below are valid device values in a `#pragma
omp target` directive:
omp_initial_device (-1) -> refers to the host CPU.
omp_invalid_device (-2) -> an intentionally invalid device, used to
trigger a runtime error.
For the 2 values discussed above flang fails with:
```
error: The device expression of the DEVICE clause must be a positive integer expression
!$OMP TARGET DEVICE(-1)
error: Must have INTEGER type, but is REAL(4)
!$OMP TARGET DEVICE(OMP_INVALID_DEVICE)
```
Issue: https://github.com/llvm/llvm-project/issues/192989
This patch renames the option to enable taskgraph support in the
runtime from OMPX_TASKGRAPH to OMP_TASKGRAPH_EXPERIMENTAL, to reflect
the feature's official status in OpenMP 6.0, but also the feature's
current work-in-progress nature.
commit-id:fa62775a
Reviewers: ro-i
Reviewed By: ro-i
Pull Request: https://github.com/llvm/llvm-project/pull/194045
The counterpart fix for clang (as too done here:
[flang-fix](https://github.com/llvm/llvm-project/pull/193669))
The incorrectly interpreted device values in the `target` directive
throws:
```
error: argument to 'device' clause must be a non-negative integer value
#pragma omp target device(-1)
^~
error: argument to 'device' clause must be a non-negative integer value
#pragma omp target device(omp_invalid_device)
^~~~~~~~~~~~~~~~~~
```
`__llvm_omp_indirect_call_lookup` takes in and returns a function
pointer, so make sure the types are correct, which includes the correct
address space.
The FE was recently changed to generate the correct code
[here](https://github.com/llvm/llvm-project/pull/192470).
With this change, three function pointer tests start passing.
Signed-off-by: Nick Sarnie <nick.sarnie@intel.com>
offload/cmake/caches/AMDGPUBot.cmake enables
RUNTIMES_amdgcn-amd-amdhsa_LLVM_ENABLE_RUNTIMES="openmp". In that
sub-build, check-openmp target doesn't exist and there is build error
`unknown target 'check-openmp'` after 18f63d1375, which makes
top-level check-openmp depend on check-openmp-amdgcn-amd-amdhsa.
In openmp, the device targets only call add_subdirectory(device), which
doesn't calls construct_check_openmp_target() and check-openmp target
doesn't exist. `ninja check-openmp-amdgcn-amd-amdhsa` also fails with
the same error before 18f63d1375.
Fix by adding construct_check_openmp_target() for device targets as well.
Assisted-by: Claude Sonnet 4.6
On s390x, the changes to `control_tool.c` cause a different return
address to be returned from the call to `print_current_address(0)`. Due
to the strictness of the current address returned by this call, this
lead to a test failure.
Since the return values of `omp_control_tool` are checked in separate
tests already, revert the changes to ensure that the return address
stays at the expected value.
Signed-off-by: Jan André Reuter <j.reuter@fz-juelich.de>
When a user calls `omp_control_tool`, a tool is attached and it
registered the `ompt_control_tool` callback, the tool should receive a
callback with the users arguments.
However, in #112924, it was discovered that this only happens after at
least one host side directive or runtime call calling into
`__kmp_do_middle_initialize` has been executed.
The check for `__kmp_init_middle` in `FTN_CONTROL_TOOL` did not try to
do the middle initialization and instead always returned `-2` (no tool).
A tool therefore received no callback. The user program did not get the
info that there is a tool attached. To fix this, change the explicit
return to a call of `__kmp_middle_initialize()`, as done in several
other places of `libomp`.
Further handling is then done in `__kmp_control_tool`, where the values
`-2` (no tool), `-1` (no callback), or the tools return value are
returned.
Also expand the tests to introduce checks where no callaback is
registered, or `omp_control_tool` is called before any OpenMP directive.
Fixes#112924
CC @jprotze, @hansangbae
Signed-off-by: Jan André Reuter <j.reuter@fz-juelich.de>
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>
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.
Let's remove it in LLVM 22.
Summary:
Recent OpenMP patches have added real support for virtual functions on
the device side. However, we don't provide some of the C++ ABI functions
that are emitted when using these. In practice these functions just call
`std::terminate` so we can just trap here. These are marked weak so they
will be overridden by a more correct implementation if not defined and
will also not extract on their own from a static library.
These commits fix issues regarding storage of tool data within
libomptarget. Both libomp and libomptarget have been modified to
accommodate this. We differentiate between two cases depending on the
type of the target region:
- merged target regions (default, without `nowait` clause): behavior
remains unchanged, tool data is stored in the thread local
RegionInterface class within libomptarget.
- deferred target regions (using `nowait` clause): tool data is moved to
`ompt_task_info_t` struct within libomp, as `RegionInterface` is thread
local and its data is lost whenever another task is scheduled on the
thread, which happens with deferred target regions.
In the new implementation, `RegionInterface` receives pointers to
`ompt_task_info_t` within libomp which are handled transparently within
libomptarget. Thus, the problem of tool data getting lost when a thread
receives a new task is resolved: `target_data` and `target_task_data`
remain set.
Another issue was the value of `task_data` which is supposed to belong
to the generating task of the region according to the OpenMP standard,
but instead had been set to the `task_data` of the target task itself
until now.
Test cases have been added which check both of these fixes.
---------
Co-authored-by: Joachim <jenke@itc.rwth-aachen.de>
This is needed as a way to support older code that was expecting
unconditional attachment to happen for cases like:
```c
int *p;
int x;
#pragma omp targret enter data map(p) // (A)
#pragma omp target enter data map(x) // (B)
p = &x;
// By default, this does NOT attach p and x
#pragma omp target enter data map(p[0:0]) // (C)
```
When the environment variable is set, such maps, where both the pointer
and the pointee already have corresponding copies on the device, but are
not attached to one another, will be attached as-if OpenMP 6.1 TR14's
`attach(always)` map-type-modifier was specified on `(C)`.
When llvm-symbolizer is not found on PATH TSan uses system's addr2line
instead. On Ubuntu 22.04 addr2line can't handle DWARF v5, which results
in failures in some libarcher tests.
This PR adds the directory of the just built LLVM binaries to PATH, to
make llvm-symbolizer available to TSan.
The changes were tested on an AArch64 machine, on which
task-taskgroup-unrelated.c was flaky. Moving the test code to a separate
function, executed 10 times, solved the issue.
Fixes#170138
Reapplication of #137828, changes:
* Workaround CMAKE_Fortran_PREPROCESS_SOURCE issue for CMake < 2.24: The
issue is that `try_compile` does not forward manually-defined compiler
flang variables to the test build environment; instead of just a
negative test result, it aborts the configuration step itself. To be
fair, manually defining these variables is deprecated since at least
CMake 3.6.
* Missing flang cmd line flags for CMake < 3.28 `-target=`, `-O2`, `-O3`
* It is now possible to set FLANG_RT_ENABLED_STATIC=OFF and
FLANG_RT_ENABLE_SHARED=OFF at the same and is the default for amdgpu and
nvptx targets. In this mode, only the .mod files are compiled --
necessary for module files in
lib/clang/22/finclude/flang/(nvptx64-nvidia-cuda|amdgpu-amd-amdhsa)/*.mod
to be available.
* For compiling omp_lib.mod for nvptx and amdgpu, the module build
functionality must be hoisted out if openmp's runtime/ directory which
is only included for host targets. This PR now requires #169909.
Move building the .mod files from openmp/flang to openmp/flang-rt using
a shared mechanism. Motivations to do so are:
1. Most modules are target-dependent and need to be re-compiled for each
target separately, which is something the LLVM_ENABLE_RUNTIMES system
already does. Prime example is `iso_c_binding.mod` which encodes the
target's ABI. Constants such as [`c_long_double` also have different
values](d748c81218/flang-rt/lib/runtime/iso_c_binding.f90 (L77-L81)).
Most other modules have `#ifdef`-enclosed code as well. For instance
this caused offload targets nvptx64-nvidia-cuda/amdgpu-amd-amdhsa to use
the modules files compiled for the host which may contrain uses of the
types REAL(10) or REAL(16) not available for nvptx/amdgpu.
#146876#128015#129742#158790
3. CMake has support for Fortran that we should use. Among other things,
it automatically determines module dependencies so there is no need to
hardcode them in the CMakeLists.txt.
4. It allows using Fortran itself to implement Flang-RT. Currently, only
`iso_fortran_env_impl.f90` emits object files that are needed by Fortran
applications (#89403). The workaround of #95388 could be reverted (PR
#169525).
If using Flang for cross-compilation or target-offloading, flang-rt must
now be compiled for each target not only for the library, but also to
get the target-specific module files. For instance in a bootstrapping
runtime build, this can be done by adding:
`-DLLVM_RUNTIME_TARGETS=default;nvptx64-nvidia-cuda;amdgpu-amd-amdhsa`.
Some new dependencies come into play:
* openmp depends on flang-rt for building `lib_omp.mod` and
`lib_omp_kinds.mod`. Currently, if flang-rt is not found then the
modules are not built.
* check-flang depends on flang-rt: If not found, the majority of tests
are disabled. If not building in a bootstrpping build, the location of
the module files can be pointed to using
`-DFLANG_INTRINSIC_MODULES_DIR=<path>`, e.g. in a flang-standalone
build. Alternatively, the test needing any of the intrinsic modules
could be marked with `REQUIRES: flangrt-modules`.
* check-flang depends on openmp: Not a change; tests requiring
`lib_omp.mod` and `lib_omp_kinds.mod` those are already marked with
`openmp_runtime`.
As intrinsic are now specific to the target, their location is moved
from `include/flang` to `<resource-dir>/finclude/flang/<triple>`. The
mechnism to compute the location have been moved from flang-rt
(previously used to compute the location of `libflang_rt.*.a`) to common
locations in `cmake/GetToolchainDirs.cmake` and
`runtimes/CMakeLists.txt` so they can be used by both, openmp and
flang-rt. Potentially the mechnism could also be shared by other
libraries such as compiler-rt.
`finclude` was chosen because `gfortran` uses it as well and avoids
misuse such as `#include <flang/iso_c_binding.mod>`. The search location
is now determined by `ToolChain` in the driver, instead of by the
frontend. Another subdirectory `flang` avoids accidental inclusion of
gfortran-modules which due to compression would result in
user-unfriendly errors. Now the driver adds `-fintrinsic-module-path`
for that location to the frontend call (Just like gfortran does).
`-fintrinsic-module-path` had to be fixed for this because ironically it
was only added to `searchDirectories`, but not
`intrinsicModuleDirectories_`. Since the driver determines the location,
tests invoking `flang -fc1` and `bbc` must also be passed the location
by llvm-lit. This works like llvm-lit does for finding the include dirs
for Clang using `-print-file-name=...`.
Extracted out of #169638. The motivation is that we want to build
Fortran module files for device triples (amdgpu-amd-amdhsa and
nvptx64-nvidia-cuda) as well, but the runtimes/ directory is only
included for host devices.
This PR itself should not change anything, including that omp_lib.mod is
only built on host devices triple. Some dependencies used for building
omp_lib.mod are hoisted out of runtimes/ as well. IMHO they all make
sense to hoist, e.g. LIBOMP_VERSION_MAJOR/LIBOMP_VERSION_MINOR should be
usable in the entire OpenMP subproject.
When a critical construct has finished, it will trigger a
critical-released event. If a tool is attached, and the `mutex_released`
callback was registered, the tool with receive an event containing the
`codeptr_ra`, the return address of the callback invocation.
All the way back in 82e94a5934, this
`codeptr_ra` was implemented by calling `__ompt_load_return_address`
with a fixed global thread id of `0`. However, this approach results in
a race-condition, and can yield incorrect results to the tool.
`__ompt_load_return_address(0)` points to the current return address of
the thread 0 in `__kmp_threads`. This thread may already execute some
other construct. A tool might therefore receive the return address of
e.g. some `libomp` internals, or other parts of the user code.
Additionally, a call to `__ompt_load_return_address` resets the
`th.ompt_thread_info.return_address` to `NULL`, therefore also affecting
the return address of thread 0. Another dispatched event, e.g.
parallel-begin might therefore not transfer any `codeptr_ra`.
To fix this, replace the fixed thread id by the `global_tid`, which is
stored just before dispatching the `mutex_released` callback.
Signed-off-by: Jan André Reuter <j.reuter@fz-juelich.de>
Move building the .mod files from openmp/flang to openmp/flang-rt using
a shared mechanism. Motivations to do so are:
1. Most modules are target-dependent and need to be re-compiled for each
target separately, which is something the LLVM_ENABLE_RUNTIMES system
already does. Prime example is `iso_c_binding.mod` which encodes the
target's ABI. Most other modules have `#ifdef`-enclosed code as well.
2. CMake has support for Fortran that we should use. Among other things,
it automatically determines module dependencies so there is no need to
hardcode them in the CMakeLists.txt.
3. It allows using Fortran itself to implement Flang-RT. Currently, only
`iso_fortran_env_impl.f90` emits object files that are needed by Fortran
applications (#89403). The workaround of #95388 could be reverted.
Some new dependencies come into play:
* openmp depends on flang-rt for building `lib_omp.mod` and
`lib_omp_kinds.mod`. Currently, if flang-rt is not found then the
modules are not built.
* check-flang depends on flang-rt: If not found, the majority of tests
are disabled. If not building in a bootstrpping build, the location of
the module files can be pointed to using
`-DFLANG_INTRINSIC_MODULES_DIR=<path>`, e.g. in a flang-standalone
build. Alternatively, the test needing any of the intrinsic modules
could be marked with `REQUIRES: flangrt-modules`.
* check-flang depends on openmp: Not a change; tests requiring
`lib_omp.mod` and `lib_omp_kinds.mod` those are already marked with
`openmp_runtime`.
As intrinsic are now specific to the target, their location is moved
from `include/flang` to `<resource-dir>/finclude/flang/<triple>`. The
mechnism to compute the location have been moved from flang-rt
(previously used to compute the location of `libflang_rt.*.a`) to common
locations in `cmake/GetToolchainDirs.cmake` and
`runtimes/CMakeLists.txt` so they can be used by both, openmp and
flang-rt. Potentially the mechnism could also be shared by other
libraries such as compiler-rt.
`finclude` was chosen because `gfortran` uses it as well and avoids
misuse such as `#include <flang/iso_c_binding.mod>`. The search location
is now determined by `ToolChain` in the driver, instead of by the
frontend. Now the driver adds `-fintrinsic-module-path` for that
location to the frontend call (Just like gfortran does).
`-fintrinsic-module-path` had to be fixed for this because ironically it
was only added to `searchDirectories`, but not
`intrinsicModuleDirectories_`. Since the driver determines the location,
tests invoking `flang -fc1` and `bbc` must also be passed the location
by llvm-lit. This works like llvm-lit does for finding the include dirs
for Clang using `-print-file-name=...`.
Clang is adding support for the new `OpenMP transparent` clause on
`task` and `taskloop` directives.
The parsing and semantic handling for this clause is introduced in
https://github.com/llvm/llvm-project/pull/166810 .
To allow the compiler to communicate this clause to the `OpenMP`
runtime, a dedicated bit in `kmp_tasking_flags` is required.
This patch adds a new compiler-reserved bit `transparent` to the`
kmp_tasking_flags` structure.
Post-commit fix of #164794 reported at
https://github.com/llvm/llvm-project/pull/164794#issuecomment-3536253493
`LLVM_LIBRARY_OUTPUT_INTDIR` and `LLVM_RUNTIME_OUTPUT_INTDIR` is used by
`AddLLVM.cmake` as output directories. Unless we are in a
bootstrapping-build, It must not point to directories found by
`find_package(LLVM)` which may be read-only directories. MLIR for
instance sets thesese variables to its own build output
directory, so should the runtimes.
Summary:
This was a lot of code that was only used for upstream LLVM builds of
AMDGPU offloading. We have a generic and fast `malloc` in `libc` now so
just use that. Simplifies code, can be added back if we start providing
alternate forms but I don't think there's a single use-case that would
justify it yet.
On AIX, it generates libomp for both static and dynamic. There is no
need to create symbolic links to libomp.so.
---------
Co-authored-by: Xing Xue <xingxue@outlook.com>
