Two fixes when using CMake < 3.28 after #209482:
* In addition to `flang`, also recognize `fakeflang` to determine
whether any workaround for CMake not completely supporting Flang is
needed. `fakeflang` is used as a shim in #209482.
* For CMake < 3.24, CMake does not reognize Flang at all and tries other
methods to detect to the compiler, including the file `CMakeTestGNU.c`.
Make `fakeflang` recognize it as a probe attempt.
This should fix the
[openmp-offload-amdgpu-clang-flang](https://lab.llvm.org/buildbot/#/builders/67)
buildbot. The buildbot is currently upgrade to a newer CMake version,
and the minimum required version of CMake will become 3.31 soon.
With #203481 where `runtimes-configure` does not depend on `flang`
anymore, the following race could happen in incremental builds: While
ninja/make builds some of the libFortran*.so libraries in a
BUILD_SHARED_LIBS=ON build, CMake tries to execute flang which tries to
load the .so libraries while they are linked. This race condition can
only happen in incremental builds because before the real bin/flang is
built completely the first time, it points to fakeflang which would be
working. Only in an incremental build, would the real bin/flang already
been built created before, pointing to the currently re-built flang.
I did not think this would be possible because CMake only needs to probe
flang once and thereafter (in the incremental build) remembers the probe
result in `CMakeFiles/<version>/CMakeFortranCompiler.cmake`. CMake does
not support changing the compiler once configured and errors-out if you
try to change `CMAKE_Fortran_COMPILER`. I do not know why/when CMake is
re-probing the compiler in some incremental builds, but has been
reported to do so in #205360.
This patch avoids any replacement of build artifacts and instead decides
in fakeflang when to call real flang or to emulate the Flang
preprocessor. The decision is made based of on the FLANG_BOOTSTRAP_PROBE
environment variable that is set only in the configure step. The feature
that allows this is unfortunately only available starting in CMake 4.2.
All suppported CMake versions before CMake 4.2 use the filename
`CMakeFortranCompilerId.F`, so make the decision based on that when
using earlier versions of CMake.
Tested with CMake 3.20, 3.28, 3.31, 4.1, and 4.2.
Fixes#205360
Add parser and semantics plumbing for configured implicit USE modules,
reusing
the normal USE-association path so public symbols and common blocks are
imported
consistently.
Support the following additional patterns that CMake may use to
introspect the Fortran compiler:
1. `__GNUC__` may be tested before `__flang__` which results in the
compiler to be identified as "GNU" instead of "LLVMFlang"
2. Invoke with `-E -cpp` to explicitly use the preprocessor
Fakeflang was added in #203481 to not have to build all of flang just to
pass CMake's compiler detection.
Tested with CMake 3.20, 3.28, and 4.4-rc.
Should fix the
[flang-aarch64-rel-assert](https://lab.llvm.org/buildbot/#/builders/29)
and [flang-aarch64-dylib](https://lab.llvm.org/buildbot/#/builders/50)
buildbots.
Add a mock driver to pass CMake's compiler introspection for
CMake_Fortran_COMPILER. It's purpose is to not having to build the full
flang compiler for the runtimes-configure phase in
bootstrapping-runtimes builds, but only when the Fortran compiler is
actually needed (e.g. flang-rt-mod, libomp-mod).
To detect LLVMFlang, CMake executes
```
${CMAKE_Fortran_COMPILER} -v -c -target=... CMakeFortranCompilerId.F
```
and expects a new file to appear in the working directory. This would
usually be an object file (e.g. ELF), but it doesn't matter for CMake as
it parses it for the preprocessor result of CMakeFortranCompilerId.F
which would appear as string literals in the binary file (CMake cannot
execute the file because it might be cross-compiling). Just passing it
through the preprocessor yields the same result. The most relevant
preprocessor definition is __flang__ which leads to
CMAKE_Fortran_COMPILER_ID="LLVMFlang".
This is more robust than #198205:
1. It does not rely on `CMake_Fortran_COMPILER_FORCED` which the CMake
manual documents as [Do not
use](https://cmake.org/cmake/help/latest/module/CMakeForceCompiler.html),
nor the undocumented `CMAKE_Fortran_COMPILER_ID_RUN`.
2. Incremental builds are more robust, there should be no risk of the
make program (ninja/make) mistakenly interpreting the empty/mock
executable as the up-to-date build artifact. Creating the shim/empty
flang executable is done in the outer bootstrapping built (rather than
in the inner runtimes build); having control over both rules that create
bin/flang allows this.
Also fixes the problem that check-flang-rt/check-openmp [do not trigger
(re-)building
flang](https://github.com/llvm/llvm-project/pull/198205#pullrequestreview-4412291879).
I think it should fix intermittend failures of the premerge-CI such as
https://github.com/llvm/llvm-project/actions/runs/27389890881/job/80947804137?pr=203400.
Design considerations:
* This relies on the way how CMake currently introspects the compiler.
However, I expect it to stay "look into the produced files" in the
foreseable future and will also not rely on runtime string concatenation
because debug builds may not ptimize them into a single string constant.
That is, there are reasons CMake can only rely on the preprocessor. The
Fortran standard does not mandate a preprocessor, yet CMake relies on
it.
* There is one situation where incremental builds to not completely
work: deleting bin/flang manually and then building runtimes-configure
will not recreate either bin/flang. No impact if runtimes-configure was
actually run before because in that case CMake has already cached the
CMAKE_Fortran_COMPILER inspection result.
* ninja does not allow two rules to create the same file (one to create
bin/flang only if it is missing and another that replaces it with the
full flang), one of the build artifacts must be undeclared. That could
be the full flang would only be created explicitly with a separate
`flang-eager` target (flang itself have the output
`bin/flang-<version>`, `bin/flang` is the symlink to it), but that would
require more intrusive changes.
Previously, FLANG_COMPILER_OPTIONS_STRING stored every argument passed
to the flang driver, including input file names. The GNU extension
compiler_options() is documented to return only the options, not the
input files. Including the input files also caused the string to exceed
ARG_MAX on large builds, producing:
posix_spawn failed: Argument list too long
Use the driver's parsed InputArgList to filter out OPT_INPUT arguments,
preserving all options and their values (e.g. `-I /path`, `-o file`).
Fixes: https://github.com/llvm/llvm-project/issues/170651
Follow-up to #197092.
That PR fixed the OpenMP target-device case by running scalar-to-array
`hlfir.assign` inlining at `-O0`, so device code would not lower through
`_FortranAAssign`.
However, running that path for normal host `-g -O0` also changed
debugging behavior: a breakpoint on a scalar broadcast like `arr = 11`
could be hit once per array element because the assignment became an
inline loop.
This patch restricts the `-O0` scalar-RHS-only inlining path to OpenMP
target-device compilation. Host `-O0` keeps the existing
`_FortranAAssign` path and debugger behavior, while device `-O0` still
avoids the runtime call.
Two focused tests cover both sides:
- host `-O0` scalar broadcast keeps `_FortranAAssign`
- OpenMP target-device `-O0` scalar broadcast avoids `_FortranAAssign`
Fixing debug locations for generated inline loops more generally is left
as separate follow-up work.
The broader debug-location issue for generated inline assignment loops
is tracked separately in #202065.
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=...`.
Add support for -fintrinsic-module-path to bbc. With #196558 the default
search path in the resource directory is determined by the driver, not
by the frontend (-fc1 and bbc). For tests of either frontend the tests
will need to append the search path themselves. Adding support for
`-fintrinsic-module-path` will allow using the same additional argument
for flang_fc1 and bbc tests.
Also rewriting the awkward tests that expect standard modules to fail
only because they do not contain a checksum. Maintaining this way of
testing became burdonsome because there are multiple ways of how default
modules are resolved. Fixing one breaks another.
Extracted out of #171515 to make that patch a bit smaller.
---------
Co-authored-by: Tarun Prabhu <tarun@lanl.gov>
Drop the user-facing options that selected the legacy non-HLFIR lowering
path, the always-true `LowerToHighLevelFIR` lowering option, and the
descriptor-discretization debug switch:
- `-flang-experimental-hlfir` and `-flang-deprecated-no-hlfir` (flang
driver and `-fc1`)
- `-hlfir` / `--hlfir` (bbc)
- `--use-desc-for-alloc` (bbc, debug)
Remove every `if (lowerToHighLevelFIR()) { ... } else { ... }` branch in
`lib/Lower/`, keeping the HLFIR side. Delete the now-unused legacy
helpers in `Bridge.cpp` (`copyVarFIR`, both
`genNoHLFIRPointerAssignment`
overloads, the legacy block of `genAssignment`) and the always-empty
`createMutableProperties` together with its four dead helpers in
`Allocatable.cpp`. Drop the corresponding `alwaysUseBox` parameter from
`createMutableBox`.
Note: tests were modified in
https://github.com/llvm/llvm-project/pull/196137
Assisted-by: AI
The flang driver never registered passes in the MLIR pass registry, so
--mlir-print-ir-before=<pass> always failed with `Cannot find option`.
This commit adds pass registration calls before CLI option parsing in
the -mmlir handler such that all ~30 pipeline passes are now selectable.
This patch moves the OpenMP offloding module attributes handling from
flang to mlir so that it can be reused in ClangIR was well.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Michael Kruse <github@meinersbur.de>
This patch adds `flang -fc1` option `-ffp-maxmin-behavior` and
propagates it throughout Flang, so that semantics context,
lowering and the pass pipeline builder can use it.
MAX/MIN intrinsic and OpenACC max/min reduction lowering
are now controlled by the option.
I kept the `Legacy` mode, which is the default and matches the current
behavior. I am going to test and merge a follow-up patch that
replaces `Legacy` with `Portable`.
RFC:
https://discourse.llvm.org/t/flang-canonical-and-optimizable-representation-for-min-max/90037
Currently, `-DLLVM_DISTRIBUTION_COMPONENTS="flang-module-interfaces"`
doesn't work. It failed to build the Fortran builtin/intrinsic modules
as distribution build, `install-distribution`.
This PR is to fix that.
When an assembly file is passed to the Flang driver, it currently fails
with a confusing internal error mentioning the unsupported `-cc1as`
tool.
This update detects assembly inputs early in the driver and emits a
clear, user-facing diagnostic explaining that Flang does not support
assembly files as input. The logic is implemented in a small helper
function and is intentionally temporary, so it can be removed once Flang
gains support for assembling inputs.
Fixes: #173528
This patch allows to set up additional compiler directive sentinel in
addition to the default `!dir$`. Some user code could use other vendor
specific compiler directive sentinel and this solution allows to add
them to the parser options.
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.
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.
When `-gpu=mem:managed` is used, allocatable arrays without explicit
CUDA data attributes are implicitly treated as managed. The
`-gpu=mem:managed` flag to enable this feature is currently only
supported in `bbc`.
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.
We have a longstanding issue in debug info that use statement is not
fully respected. The problem has been described in
https://github.com/llvm/llvm-project/issues/160923. This is first part
of the effort to address this issue. This PR adds infrastructure to emit
`use` statement information in FIR, which will be used by subsequent
patches to generate DWARF debug information.
The information about use statement is collected during semantic
analysis and stored in `PreservedUseStmt` objects. During lowering,
`fir.use_stmt` operations are emitted for each `PreservedUseStmt`
object. The `fir.use_stmt` operation captures the module name, `only`
list symbols, and any renames specified in the use statement. The
`fir.use_stmt` is removed during `CodeGen`.
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=...`.
This is a reapply the original patch (#169137) with the flang-rt unit
test changes limiting it to linux platform only.
Additionally accommodated style changes from Peter Klausler (#170227)
show_descriptor intrinsic prints details of a descriptor (extended
Fortran pointer).
It accepts a descriptor for any type and rank, including scalars.
Requires use of flang_debug module.
Example:
```
program test
use flang_debug
implicit none
integer :: a(4) = (/ 1,3,5,7 /)
call show_descriptor(a(1:3))
end program test
```
and its output:
```
Descriptor @ 0x7ffe01ec6a98:
base_addr 0x563b7035103c
elem_len 4
version 20240719
rank 1
type 9 "INTEGER(kind=4)"
attribute 0
extra 0
addendum 0
alloc_idx 0
```
show_descriptor intrinsic prints details of a descriptor (extended
Fortran pointer).
It accepts a descriptor for any type and rank, including scalars.
Requires use of flang_debug module.
Example:
program test
use flang_debug
implicit none
integer :: a(4) = (/ 1,3,5,7 /)
call show_descriptor(a(1:3))
end program test
and its output:
Descriptor @ 0x7ffe01ec6a98:
base_addr 0x563b7035103c
elem_len 4
version 20240719
rank 1
type 9 "INTEGER(kind=4)"
attribute 0
extra 0
addendum 0
alloc_idx 0
dim[0] lower_bound 1
extent 3
sm 4
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=...`.
This relands #167348.
The original PR was reverted due to a reported build failure, which was
later diagnosed as a local issue in the developer’s checkout or build
state. See discussion here:
https://github.com/llvm/llvm-project/pull/163659#discussion_r2511546964
No additional changes have been made in this reland.
This change moves option-related code from clangDriver into a new
clangOptions library.
This refactoring is part of a broader effort to support driver-managed
builds for compilations using C++ named modules and/or Clang modules.
It is required for linking the dependency scanning tooling against the
driver without introducing cyclic dependencies, which would otherwise
cause build failures when dynamic linking is enabled.
In particular, clangFrontend must no longer depend on clangDriver
for this to be possible.
This PR is motivated by the following review comment:
https://github.com/llvm/llvm-project/pull/152770#discussion_r2430756918
Some operations like the gpu.func have arguments that need to stay in
place while rewriting the signature. This is the case for the workgroup
and private attribution.
Update the target rewrite pass to be aware of that when adding argument
at the end of the function signature. If any trailing arguments are
present, the new argument will be inserted just before them.
Support for multi-image features has begun to be integrated into LLVM. A
new dialect which simplifies lowering to PRIF wil be proposed in this
PR.
The initial definition of this dialect (MIF) is based only on operations
already upstreamed in LLVM and the current lowering will be moved to
this dialect.
---------
Co-authored-by: Dan Bonachea <dobonachea@lbl.gov>
Co-authored-by: Valentin Clement (バレンタイン クレメン) <clementval@gmail.com>
Implements genAllocate, genFree, and genCopy for FIR pointer types
(fir.ref, fir.ptr, fir.heap, fir.llvm_ptr) in the OpenACC
PointerLikeType interface.
- genAllocate: Uses fir.alloca for stack types, fir.allocmem for heap
types. Returns null for dynamic/unknown types (unlimited polymorphic,
dynamic arrays, dynamic character lengths, box types).
- genFree: Generates fir.freemem for heap allocations. Returns false if
original allocation cannot be found.
- genCopy: Uses fir.load+fir.store for trivial types (scalars),
hlfir.assign for non-trivial types (arrays, derived types, characters).
Returns false for unsupported dynamic types and box types.
Adds comprehensive MLIR tests covering various FIR types and edge cases.
When working on privatization, it is easier to work with fir.box
explicitly in memory, otherwise, there is no way to express that the
fir.box will end-up being a descriptor address in FIR which makes it
hard to deal with data management.
However, introducing fir.ref<fir.box> early can pessimize early HLFIR
optimization because it is harder to reason about the aliasing of
`fir.ref<fir.box>` because of the extra memory indirection.
This patch introduces a pass that turns acc `!fir.box<T>` recipes into
`!fir.ref<!fir.box<T>>` recipes and updated the related recipe usages to
use `!fir.ref<!fir.box<T>>` (creating new alloca+store+load).
It is added to flang and not OpenACC because it is specific to the
`fir.box` type, so it makes little sense to make it an OpenACC generic
pass and to create a new OpenACC dialect type interface for this use
case.
This PR introduces a new `ConvertComplexPow` pass for Flang that handles
complex power operations. The change forces lowering to complex.pow
operations when `--math-runtime=precise` is not used, then uses the
`ConvertComplexPow` pass to convert these operations back to library
calls.
- Adds a new `ConvertComplexPow` pass that converts complex.pow ops to
appropriate runtime library calls
- Updates complex power lowering to use `complex.pow` operations by
default instead of direct library calls
#158722 Adds a new `complex.powi` op enabling algebraic optimisations.
The build system used to create `.f18.mod` variants for all `.mod`
files, but this was removed in #85249. However, there is a leftover that
still creates these when building `openmp` in the project configuration.
It does not happen in the runtimes configuration.
Both clang and gfortran support the -fopenmp-simd flag, which enables
OpenMP support only for simd constructs, while disabling the rest of
OpenMP.
Implement the appropriate parse tree rewriting to remove non-SIMD OpenMP
constructs at the parsing stage.
Add a new SimdOnly flang OpenMP IR pass which rewrites generated OpenMP
FIR to handle untangling composite simd constructs, and clean up OpenMP
operations leftover after the parse tree rewriting stage.
With this approach, the two parts of the logic required to make the flag
work can be self-contained within the parse tree rewriter and the MLIR
pass, respectively. It does not need to be implemented within the core
lowering logic itself.
The flag is expected to have no effect if -fopenmp is passed explicitly,
and is only expected to remove OpenMP constructs, not things like OpenMP
library functions calls. This matches the behaviour of other compilers.
---------
Signed-off-by: Kajetan Puchalski <kajetan.puchalski@arm.com>
The default linker can be changed by a CMake variable
CLANG_DEFAULT_LINKER. However, it also changes the default linker
invoked by clang. In fact, there already exists FLANG_DEFAULT_LINKER,
but it does not work. This patch fixes it.
Note that FLANG_DEFAULT_LINKER will have the same value as
CLANG_DEFAULT_LINKER unless it is defined explicitly. That means this
patch does not affect the current behavior.
Fixes#73153
---------
Co-authored-by: Michael Kruse <github@meinersbur.de>
At the moment, there is no established way to emit LLVM IR before
optimization in LLVM. tco can partially does, but the optimization level
is fixed to 2. This patch adds -O flag to tco.
Note that this is not completely equivalent to the frontend option. tco
does not accept -O flag without numbers, and the default optimization
level is not 0 but 2.
Re-apply "[flang][cmake] Fix bcc dependencies (#125822)"
It was overwritten due to an automatic merge gone wrong for #124416.
`git cherry-pick f9af5c145f40480d46874b643ca2b1237e9fbb2a` applied in
97cf061e83 ignored the renaming of
FortranCommon into FortranSupport after #125822.
Original commit message:
The Fortran libraries are not part of MLIR, so they should use
target_link_libraries() rather than mlir_target_link_libraries().
This fixes an issue introduced in #20966.
