There is a known issue with these tests (see
https://github.com/llvm/llvm-project/issues/35661).
It looks that the behaviour is very architecture specific and it was
somehow solved for aarch64 but no mention to riscv64.
This adds support for the OpenMP interop construct, which enables
interoperability with foreign runtime environments (e.g., CUDA, HIP).
The init, use, and destroy action clauses are lowered from the Fortran
parse tree to MLIR interop ops and translated to the appropriate runtime
calls. The omp_lib module is extended with interop query API interfaces,
property constants, and return code constants. A semantics fix relaxes
the depend/targetsync constraint for use/destroy directives where the
interop type was established at a separate init site. Unsupported depend
clauses and prefer_type selector-list forms emit explicit diagnostics
instead of being silently dropped.
Assisted-by: Claude Opus 4.6
Fixes#211135.
`openmp/module/CMakeLists.txt:29` gates the GPU-only Fortran compile
options on `"^amdgcn|^nvptx"`, while `openmp/CMakeLists.txt:176-177`
selects host-vs-device layout for the same build using
`"^amdgpu|^amdgcn|^nvptx|^spirv64"` against both
`LLVM_DEFAULT_TARGET_TRIPLE` and `CMAKE_CXX_COMPILER_TARGET`.
All four offload cache files use the triple `amdgpu-amd-amdhsa`, which
`^amdgcn` does not match, so `-nogpulib -flto` are silently not applied
to `libomp-mod` in the recommended AMDGPU offload configurations.
Compute the test once as `LIBOMP_TARGET_IS_GPU` in
`openmp/CMakeLists.txt` and use it at both sites, rather than
duplicating a widened regex. The conditions differ, not just the
patterns: copying the regex alone would leave a build that sets
`CMAKE_CXX_COMPILER_TARGET` without `LLVM_DEFAULT_TARGET_TRIPLE` still
taking the device path in `openmp/` while `libomp-mod` misses the flags.
`libomp-mod` compiles Fortran, so `CMAKE_Fortran_COMPILER_TARGET` is
also consulted; neither site did before.
Evaluated with CMake's regex engine:
| triple | before | after |
|---|---|---|
| `amdgpu-amd-amdhsa` | 0 | 1 |
| `amdgcn-amd-amdhsa` | 1 | 1 |
| `nvptx64-nvidia-cuda` | 1 | 1 |
| `spirv64-amd-amdhsa` | 0 | 1 |
| `x86_64-unknown-linux-gnu` | 0 | 0 |
`^spirv64` only brings `module/` in line with
`openmp/CMakeLists.txt:176`, which already routes spirv64 to `device/`.
Host builds are unaffected.
Roughly five other sites carry the same `amdgcn`-only pattern
(`offload/CMakeLists.txt:30`, `flang-rt/CMakeLists.txt:126`,
`flang-rt/lib/runtime/CMakeLists.txt:317`,
`flang-rt/cmake/modules/AddFlangRT.cmake:298`,
`cmake/Modules/GetToolchainDirs.cmake:118`) and are left for a
follow-up.
No test: configure-time logic, no test mechanism exists in `openmp/`.
This affects performance-critical applications on large AMD GPU
supercomputers, including [MFC](https://github.com/MFlowCode/MFC).
All numbers above come from the validated reproducers included with this
report and are independently reproducible; they stand on their own.
This was found and root-caused with the assistance of AI tools.
The "oncore" flavor of the hierarchical barrier code uses a single
uint64 to hold both a barrier state *and* a set of flags for the current
node's "leaf kids" in the tree.
To make this work, the barrier state is placed in the least-significant
byte of the uint64, and the flags for leaf kids are placed in other
bytes of the uint64 starting from the most-significant byte to represent
the first child.
At least, this is how it works on little-endian systems. On big-endian
hosts, the current code unfortunately places the leaf kid flags starting
from the *least* significant byte of the uint64, where they will overlap
and clobber the barrier state byte, resulting in corrupted barrier
behavior.
To fix this, this PR changes the child flag offsets to always start with
the MSB, on both big- and little- endian hosts. This was complicated a
bit by the following issues:
- The byte offset was stored "off-by-one" for some reason. This makes it
impossible to represent the MSB on big- endian systems (i.e. byte 0,
which would have to be represented by -1 if offset by one, which does
not fit into the uint8 offset field).
Fixed by storing and using the "offset" field as the actual byte number,
not off-by-one.
- The "offset" field was never used for the master node, but it was
still computed. That computed value was also invalid as it pointed
outside the target uint64, but that didn't matter as it was unused. For
big-endian systems, however, the computation would have resulted in a
*negative* value, which again cannot be stored in the uint8 field.
Fixed by skipping the (unused) computation on the master node and
setting the "offset" field to a dummy value.
This is intended to be NFC on little-endian machines.
When targeting arm64ec, neither KMP_ARCH_X86_64 nor KMP_ARCH_AARCH64 is
defined.
This fixes a compilation warning when building openmp for mingw/arm64ec.
In __kmpc_target_init, thread 0 initializes the team state in LDS
(HasThreadState = 0, ThreadStates = nullptr) and then releases the other
threads with synchronize::threadsAligned(atomic::relaxed). Because the
relaxed ordering emits no memory fence, the initializing LDS stores are
not guaranteed to be visible to the worker threads before they proceed.
A worker thread can then read the uninitialized team state and produce
wrong results or crash. This is the flow that causes the race as I
understand it.
```
__kmpc_target_init (Kernel.cpp:107)
-> initializeRuntime (Kernel.cpp:38)
-> state::init (State.cpp:286)
-> TeamState.init(IsSPMD) (State.cpp:295)
-> HasThreadState = false (State.cpp:248) // <-- the value later read stale
ThreadStates = nullptr (State.cpp:296)
-> synchronize::threadsAligned(atomic::relaxed) (Kernel.cpp:115) // <-- insufficient barrier:
// relaxed emits no fence, so the state stores above are not published to the other threads
... worker threads continue past the barrier ...
__kmpc_parallel_60 (Parallelism.cpp:143)
if (OMP_UNLIKELY(!if_expr || state::HasThreadState || ...)) (Parallelism.cpp:158)
^ reads HasThreadState from LDS; a stale/unpublished value (!= 0)
diverts the worker onto the wrong (serialized) path
```
The fix changes the barrier at Kernel.cpp:115 from atomic::relaxed to
atomic::acq_rel so that the memory fences are emitted.
Reproducing the problem requires an `if` clause with a non-constant
condition on the target region. The worker's read of HasThreadState
originates from the serialized-region check in __kmpc_parallel_60. When
the `if` condition is constant (or absent), the optimizer can prove that
branch is dead and eliminates the HasThreadState load entirely, so the
race has nothing to observe. A non-constant `if` keeps if_expr, and
hence the LDS read alive, exposing the problem.
I have added a Fortran offload regression test that launches a target
region many times to make the timing-dependent race likely to surface.
Fixes https://github.com/llvm/llvm-project/issues/208698.
Assisted-by: Cursor
Offload tests failed after introducing the new triple. This PR attempts
to address that. It includes the changes in
https://github.com/llvm/llvm-project/pull/208551. In addition, it also
made following changes:
- Updated flang builder that our buildbot uses;
- Updated the CMakeLists for offload and AMDGPU device runtime (a little
duplications to avoid breaking other buildbots);
- Added per target linker path and mapping for lit substitution/features
in lit config;
- Updated hard-coded check lines in the tests.
This PR reduces the failed offload tests from 246 to 2 on my test runs
locally. Test results and the two failed tests:
```
Failed Tests (2):
libomptarget :: amdgpu-amd-amdhsa :: offloading/fortran/declare-target-common-block-main.f90
libomptarget :: amdgpu-amd-amdhsa :: sanitizer/use_after_free_2.c
Total Discovered Tests: 3478
Skipped : 77 (2.21%)
Unsupported : 341 (9.80%)
Passed : 3053 (87.78%)
Expectedly Failed: 5 (0.14%)
Failed : 2 (0.06%)
```
I was not able to identify the commits for the two failed tests yet
(didn't look like flakiness), will try again later.
Co-authored-by: Jan Patrick Lehr <JanPatrick.Lehr@amd.com>
An internal review flagged the use of `getenv` when reading the OMPT
tool library path from the environment and passing it to the loader as a
potential vuln.
This patch replaces the use of getenv in question with the use of
secure_getenv on glibc platforms.
On non glibc platforms, no change is implemented.
__kmp_wait in kmp_dispatch.h is a static function template in a header,
so any TU that includes it without instantiating it trips
-Wunused-template (kmp_runtime.cpp, kmp_affinity.cpp, kmp_global.cpp,
kmp_settings.cpp). It is used by kmp_dispatch.cpp and
kmp_dispatch_hier.h. Drop static, which the comment above it already
suggests.
Part of #202945
This patch fixes an issue where the combination of LIBOMP_ENABLE_ARM64X
and LLVM_PER_TARGET_RUNTIME_DIR=On led to only the arm64 library being
installed. With this fix, the arm64ec and arm64 .lib files are both
installed, and the arm64x dll is the one installed to the binary dir.
Since 82e94a5934, `ompt_get_num_devices`
was hard coded to always provide a return value of `1`, regardless of
the actual number of devices. Tools relying on this return value were
henced forced to use other approaches to estimate the number of
available devices.
To improve the situtation, map the returned value to the one provided by
`omp_get_num_devices()`. This does not resolve the issue completely
though. When OMPT is initialized through `libomptarget.so`, the
PluginManager, providing the number of devices, is not initialized until
after OMPT has been fully set up. This means that tools, trying to
retrieve the number of devices during the _initialize_ callback, will
still receive the incorrect number of devices.
Still, this is a significant improvement compared to the prior state
which provided an incorrect result for most of the program runtime.
Closes#196829
---------
Signed-off-by: Jan André Reuter <j.reuter@fz-juelich.de>
This adds a dedicated Flang OpenMP Support page for tracking OpenMP
feature support that entails modifications to Flang compiler components.
The expectation is that all other OpenMP feature work will continue to
be tracked under the Clang OpenMP support page.
Tables are added for each released OpenMP version since 4.0, and an
additional for the next future release. A Notes column describes current
status, and a separate column is added for a developer to record that
they are working on a given feature.
Two build failures reported after #204260
* Unix Makefiles generator stops working: The cause is that the rules
for building each OBJECT library lands in its own Makefile, e.g.
`flang_rt.mod.fortran.builtins.dir/build.make` and
`libomp-mod.dir/build.make`. Trying to inject dependencies directly for
build rules in the other file does not work.
* `__ppc_types.f90` not tracked: Forgotten in #204260 due to being only
conditionally enabled for PowerPC targets.
The solution for both is to just remove the workaround for CMake not
recognizing modules uses declared using `intrinsic` which caused these
problems. This PR promotes the `use` constructs in the module sources to
normal dependencies that are not ignored by CMake.
The `intrinsic` modifier changes the search path to only look for such a
module in `-fintrinsic-modules-path`. The difference is only
theoretical:
1. When compiling the intrinsic modules, there are no other search paths
than for the intrinsics anyway
2. Users should strongly avoid naming their modules the same as an
intrinsic module
3. Most of our intrinsic sources don't even use the `intrinsic` modifier
in the first place (e.g.
1c9412432f/flang-rt/lib/runtime/__cuda_builtins.f90 (L13)).
That is, if there was a problem with lookup ambiguity, these would have
already been a problem for those.
4. The checksum of used modules is only added into the .mod file (the
only reason why modules would need to be transitively rebuilt) when a
`use` statement appears. Many intrinsic modules don't explicitly use the
modules that are added implicitly by the compiler, such as
`__fortran_builtins`, and hence do not even need to be rebuilt.
I started this PR with a tested-working fix
([71c5e7f0ffcf2ebd58812d2e2812b22663be1631](https://github.com/llvm/llvm-project/pull/205634/changes/BASE..71c5e7f0ffcf2ebd58812d2e2812b22663be1631))
to the workaround code. But given the points above, there seems to be no
benefit of keeping the workaround code handling CMake version < 4.5
around just for some intrinsic modules to keep the `intrinsic` modifier
with no practical effect. A non-workaround path using CMake's
`Fortran_BUILDING_IN(S)TRINSIC_MODULES` setting had to be added in any
case for Unix Makefile generators (reported issue 1.) because injecting
dependencies is not possible with Unix Makefiles as stated, but
`Fortran_BUILDING_IN(S)TRINSIC_MODULES` also does not work with the
Ninja generator. Avoiding `use, intrinsic` keeps just one configuration
path.
I tested that modules are properly updated with Ninja and Unix
Makefiles:
* Build from scratch
* Modifying `__fortran_builtins.f90` rebuilds its dependent modules
* Modifying `iso_c_binding.f90` rebuilds its dependent modules
(omp_lib.mod)
llvm-project is home to many sphinx documentation sites, each with
configuration quirks and bespoke extensions.
The sphinx config model makes sharing code somewhat difficult. There
are options like sphinx-multiproject, but some of our docs builds are
out of the source tree while some are done out of the binary tree, so
the multiproject configuration itself would need to be generated. It
also would impose more uniformity around extensions than required.
This change instead creates a python package at utils/docs/llvm_sphinx
and makes it available to all sphinx-build processes via PYTHONPATH.
Each conf.py does not modify its own sys.path because not all builds are
out of the source tree, so there isn't a stable relative path to use to
refer to the utils/docs/ directory.
Type checking via pyright in new package is pinned to being python 3.8
compatible.
The myst slug script from llvm/docs is promoted to be the default,
with a slight edit to targets needed in FlangDriver.md to adapt to the
change.
The ghlinks extension from clang gets lifted to be the first generic
extension, although it is still only used in clang currently. I used it
as an example of a general extension that might be useful for other
projects, but I also intend to add a new generic extension in a future
patch.
As part of the move ghlinks is refactored a bit:
* Rather than have a main function directly to run its tests, those
tests are now run via the command-line entrypoint to the new package,
e.g. `python utils/docs --test` will now replace
`python clang/docs/ghlinks.py --test`. This makes the command-line
more pithy (`python utils/docs/llvm_sphinx/ext/ghlinks --test` is a
bit long), and makes the default behavior when running be to
include utils/docs in the sys.path, so imports can be absolute and
the behavior is as close to the CMake targets as possible.
* The static files that were previously written to a tempdir during
testing are just committed directly in git. The assumption here is
that the original version was taking pains to avoid polluting the
clang/docs directory with test files that would confuse sphinx-build,
and without that limitation the workaround can be removed.
* Some typing-related changes to make it strictly python 3.8 compatible.
Change-Id: Ie16de273f74973f163dbf7fe9d22d80a466d051f
CMake currently intentionally ignores intrinsic dependencies. flang-rt
already had a workaround using target-level dependencies, but it does
not know about dependencies between .mod files created within the same
add_library that CMake ignores. As a result, as reported in #203549,
updating a .mod did not trigger rebuilding the .mod files that depend on
it. Specifically, .mod files store the checksum of used .mod files which
need to be updated and therefore require transitive rebuidling.
As mentioned, CMake already adds this file-level dependency itself for
non-intrinsic modules dependencies. In this PR we are injecting the
additional dependencies that CMake does not add via OBJECT_DEPENDS.
Three caveats:
1. Using OBJECT_DEPENDS for dependencies between modules of the same
OBJECT library makes Ninja complain about circular dependencies. To
avoid, split __fortran_builtins.f90 and __cuda_builtins.f90 into their
own OBJECT libraries each.
2. The dependency cannot be on the .mod files. Because of how CMake's
dependency mechanism works, the dependency scanning runs only after
ensuring that the OBJECT_DEPENDS files exist. So if they don't exist
yet, we get a missing dependency error. To avoid, we depend on the .o
file instead.
3. Generator expressions do not work in OBJECT_DEPENDS. That is, we
cannot use `$<TARGET_FILES:flang_rt.mod.fortran.builtins>`, but
fortunately we can use OBJECT_OUTPUTS to make the location predictable.
At some point in the future,
https://gitlab.kitware.com/cmake/cmake/-/issues/26803 should be resolved
and become the minimum required version to build LLVM, in which case
these workarounds can be removed.
This is a part of a series of patches that rework OpenMP cross-team
reductions.
This patch changes the cross-team reduction runtime to no longer work
through larger number of teams in chunks. Instead, we allocate a
suitable-sized global buffer for the team values and let all teams run
at once. The last team that finishes uses a strided loop to reduce the
team values from the global buffer.
We also use `mapping::getNumberOfThreadsInBlock()` instead of
`omp_get_num_threads()` because the reduction of the team values runs
outside of the parallel region device code, which would make
`omp_get_num_threads()` always return 1. For Generic-SPMD mode, we also
want to use all available threads, which means that we need to copy the
reduction data from LDS (where it lives in that mode by default) to
scratch in codegen before calling the cross-team reduction.
Performance:
All performance tests can be reproduced with
https://github.com/ro-i/xteam-test @ commit
2f09ae1f566f13189d20b414d8b83bf2986564d2. To reproduce, simply create a
`local.mk` file in the cloned directory with a suitable `OFFLOAD_ARCH`
for your machine and `CXX_trunk` + `CXX_trunk_dev` set to the paths of
the clang++ binaries for llvm/main and this patch. (llvm/main should
best be at the commit that is currently the base for this PR. At the
moment, this is fe87c971bf). Then, run
`make trunk trunk_dev` to build the benchmark binaries for 208 and 10400
teams. Run them with `./run_bench.sh -rq -n10 red_trunk_208
red_trunk_dev_208 red_trunk_10400 red_trunk_dev_10400` to get the avg
performance numbers over 10 rounds.
This tests multiple reduction workloads, including reductions that run
in the Generic-SPMD mode, with 208 teams and with 10400 teams, both à
512 threads, and with a reduction array size of 177,777,777. I tested on
a gfx942 and didn't find any regressions - here are some numbers showing
the performance of this patch relative to the baseline:
```
red_comb_sep_arr_32 double dev_208: +84.37% dev_10400: +54.06%
red_sum_arr_32 double dev_208: +9.72% dev_10400: +51.29%
red_comb double dev_208: +2.73% dev_10400: +8.73%
red_comb_sep double dev_208: +1.89% dev_10400: +87.13%
red_dot double dev_208: +1.46% dev_10400: +25.66%
red_indirect double dev_208: +1.51% dev_10400: +23.54%
red_kernel_part double dev_208: +1.27% dev_10400: +88.28%
red_max double dev_208: +1.29% dev_10400: +22.69%
red_mult double dev_208: +1.96% dev_10400: +22.02%
red_sum double dev_208: +2.03% dev_10400: +22.00%
red_pi double dev_208: +1.08% dev_10400: +1.22%
red_comb_sep_arr_32 uint dev_208: +139.10% dev_10400: +88.02%
red_sum_arr_32 uint dev_208: +49.70% dev_10400: +143.24%
red_dot uint dev_208: +0.77% dev_10400: +24.91%
red_max uint dev_208: +3.43% dev_10400: +36.61%
red_sum uint dev_208: +4.56% dev_10400: +36.95%
red_comb_sep_arr_32 ulong dev_208: +85.22% dev_10400: +58.17%
red_sum_arr_32 ulong dev_208: +9.01% dev_10400: +55.14%
red_dot ulong dev_208: +2.94% dev_10400: +26.89%
red_max ulong dev_208: +2.83% dev_10400: +23.10%
red_sum ulong dev_208: +1.59% dev_10400: +22.82%
red_comb_sep_arr_32 Value dev_208: +29.88% dev_10400: +24.17%
red_sum_arr_32 Value dev_208: +7.26% dev_10400: +38.14%
red_dot Value dev_208: +2.65% dev_10400: +8.60%
red_max Value dev_208: +2.86% dev_10400: +4.77%
red_sum Value dev_208: +0.47% dev_10400: +10.22%
```
This patch uses ideas from Johannes Doerfert, ideas from the AOMP
cross-team reduction implementation, and was assisted by Claude.
This commit extends the record reporting mechanism:
- `LIBOMPTARGET_RECORD_REPORT_FILENAME` enables the reporting mechanism
and allows specifying the name of the output file.
- The report of recorded kernels are ordered in recording order. This is
really useful for tests that need to record and replay more than one
kernel.
KMP_CANCEL_THREADS was a preprocessor switch in kmp.h, with Android and
WASI explicitly #undef-ing it. Move the control to CMake:
- Detect pthread_cancel via check_symbol_exists()
- Drive KMP_CANCEL_THREADS from that result, emitted as a 0/1 #define in
kmp_config.h.cmake (overridable with -DLIBOMP_USE_CANCEL_THREADS=OFF).
- Drop the Android/WASM special-casing
Guard dlerror() result against NULL before passing to fprintf to avoid
confusing "(null)" output. Also guard dli_fname against NULL on the
success path before calling strrchr.
Assisted-by: Claude Sonnet 4.6
See rationale in the commit adding kmp_str_ref.
This commit introduces kmp_vector, a class intended primarily for small
vectors. It currently only includes methods I need at the moment, but
it's easily extensible.
libomp currently has two limitations:
1) although it's C++, it doesn't link against the C++ stdlib 2) it
cannot link against the implementation of LLVM ADTs
These limitations shall not be altered at the moment.
As a result, this commit introduces kmp_str_ref, which is similar to
LLVM's StringRef. It currently only includes methods I need at the
moment, but it's easily extensible.
The files omp_lib.h and omp-tools.h are the outputs of two
configure_file invocations which specify the full path of the outputs.
Use these full paths in LibompExports.cmake so they can actually be
found.
The previous attempt at this (b7da956501)
still broke standalone builds. Now I have locally tested standalone
flang, runtimes (with openmp), lldb, combined builds, and the utils
script. Hopefully that covers everything this time, and gets everything
into a more consistent state (always using the HandleDoxygen script in
the same way, included exactly once as required by the cmake design).
This patch prevents `omp_set_num_teams()` and
`omp_set_teams_thread_limit()` from updating teams-related ICVs when
called from restricted runtime contexts.
The non-implicit parallel-region case follows the OpenMP 5.1
restriction. The active `teams`-region case is handled defensively
because these ICVs are device-scoped and updating them during an active
`teams` region can affect later teams execution.
The calls now warn and return without updating the ICVs.
Fixes#194426.
Reverts llvm/llvm-project#191501 as cmake CI is having an issue with it:
```
-- Doxygen enabled (1.14.0).
CMake Error at /work/as-worker-4/publish-doxygen-docs/llvm-project/cmake/Modules/HandleDoxygen.cmake:29 (add_custom_target):
add_custom_target cannot create target "doxygen" because another target
with the same name already exists. The existing target is a custom target
created in source directory
"/work/as-worker-4/publish-doxygen-docs/llvm-project/llvm". See
documentation for policy CMP0002 for more details.
Call Stack (most recent call first):
docs/CMakeLists.txt:59 (include)
```
Summary:
This PR cuts `flang` out of the core runtimes configure dependency. We
will need the runtimes infrastructure to handle `flang` module
generation, but this dependency poisons the entire dependency stack.
`flang` and `mlir` are by far the heavily parts of the LLVM stack and
for distribution we want to only build it when absolutely necessary,
which as of now is only to install flang module files.
The approach here is to simply remove the `flang` target from the core
dependency tree, but intead configure it for the top-level `module`
targets which are part of `all`. To make this work we need to pass
COMPILER_WORKS and set up a dummy location so that configuration passes.
it's a little backdoor, but this is an extremely important quality of
life improvement for LLVM distribution support.
This is to address the error appearing when building this code with
somewhat more recent compilers:
```
Use of undeclared identifier 'malloc'
```
Such inclusion has already been added to the OmptTester.cpp file.
Before this PR, omp_lib.h is emitted to `${PREFIX}/include` or
`${PREFIX}/lib/clang/<version>/include` (install prefix) and
`${PREFIX}/runtime/src/omp_lib.h` (builddir prefix). It is never found
there because the driver only adds `${PREFIX}/include/flang/OpenMP` to
the include path.
Fix the `omp_lib.h` include by using the same mechanism as the
omp_lib.mod; that is, move it to
`${PREFIX}/lib/clang/<version>/finclude/flang/<target-triple>`. The
search path is already added by the driver via
`-fintrinsics-modules-path` by the driver. Although omp_lib.h currently
does not contain anything target-specific, it could do so in the future
and I don't think it is worth the effort to add a mechanism without the
target triple. It should also me consistent with omp_lib.mod.
The changes in detail consist of:
1. Move the omp_lib.h output in the builddir to
`${RUNTIMES_OUTPUT_RESOURCE_MOD_DIR}`. This already takes care of
whether it is a bootstrapping build or not.
3. Move the omp_lib.h install dir to
`${RUNTIMES_INSTALL_RESOURCE_MOD_PATH}`.
4. Remove the implicit search path `include/flang/OpenMP` from the
frontend. There is nothing in there anyway.
5. Hardcoding the include search path for testing to the
`LLVM_RUNTIME_TARGETS=default` build becomes unnecessary. This was way
the `include-omp-header.f90` test was still passing, although it would
not work outside the regression tests. Essentially, it tested
lit.site.cfg, not the driver.
6. Replace the old `include-omp-header.f90` test. It created a temporary
`omp_lib.h` that interferes with any other test that use `include
omp_lib.h` (there currently isn't but I originally intended to add the
replacement as an additional omp_lib.h test which resulted in a flaky
test while the original test was there). Due to how the %flang(_fc1)
substitution works, lookup order may also vary.
Renames SphinxQuickstartTemplate.rst to SphinxQuickstartTemplate.md as
an isolated commit to preserve blame history. The file content is not
yet valid Markdown; the rewrite follows in a stacked PR.
Cross-references in MarkdownQuickstartTemplate.md, README.txt, and
openmp/docs/README.txt are updated accordingly.
See RFC:
https://discourse.llvm.org/t/rfc-make-myst-markdown-the-llvm-docs-format-rip-rest/90840
Working on enabling the build of OpenMP and Offload in pre-merge checks
surfaced this unused var and pre-merge checks run with -Werror.
As I did not see where it should be used, remove the variable to address
the warning.
The pre-merge running into the warning as error is
https://github.com/llvm/llvm-project/actions/runs/26826349862/job/79094823845?pr=174955
Reapplication of #137828 and #169638
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).
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.
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.
Currently the dependencies between builtin modules and `omp_lib.mod`
seem to be incorrect:
https://github.com/llvm/llvm-project/pull/174474#issuecomment-3880189581
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 (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).
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=...`.
Summary:
This check exists to encode the policy that this is only intended to be
built with a just-built compiler. In practice it's a little too strict
and breaks pretty much every six months when the version bumps or when
people try to build a separate patch. Just demote to a warning.
Summary:
This target is missing, it's the expected behavior for all LLVM
components to have a way to install them individually as components.
This allows us to selectively install offload versus other pieces of the
runtime. Also make this and the openmp handling canonical with libcxx.
Summary:
This pattern is consistent throughout all the runtimes and is what the
top-level `install-openmp-<triple>` corresponds to. It should be
provided and used.
This fixes a warning in omptest about a set but unused variable. The var
was intended to control whether colored logging output is created.
That logic has been moved into the `Logger` itself.
PR #192687 Introduces a dependency to the Fortran intrinsic module when
building `openmp` Fortran modules, which requires a Flang enabled llvm
build in order to build `openmp` Fortran modules.
This PR is to add a cmake option `LIBOMP_FORTRAN_MODULES_ONLY` to allow
users to build 'openmp` Fortran modules only for Flang without building
the libomp runtime library.
This will allow libomp.a/so build still be independent from the Flang
build as before.
E.g. To build `openmp` Fortran modules only for Flang, one would need to
use the following options.
```
cmake \
...
-DLIBOMP_FORTRAN_MODULES_ONLY=ON \
-DLLVM_ENABLE_PROJECTS="flang" \
-DLLVM_ENABLE_RUNTIMES="openmp" \
...
Add new enum values, structs and variables to `omp-tools.h` header,
according to the OpenMP v6.0 specification.
Update `openmp` and `offload` tools headers to recognize the new values
to ease testing once those features are implemented.
Since no feature is implemented here, update the docs to mention
`partial` support, pointing to this PR for the enums.
---------
Signed-off-by: Jan André Reuter <j.reuter@fz-juelich.de>
