A CMake change included in CMake 4.0 makes `AIX` into a variable
(similar to `APPLE`, etc.)
ff03db6657
However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to
`AIX` and `if` auto-expands variable names in CMake. That means you get
a double expansion if you write:
`if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")`
which becomes:
`if (AIX MATCHES "AIX")`
which is as if you wrote:
`if (ON MATCHES "AIX")`
You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}",
due to policy
[CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054)
which is on by default in 4.0+. Most of the LLVM CMake already does
this, but this PR fixes the remaining cases where we do not.
Includes CMake files and placeholder header, library, test tool, regression
test and unit test.
The aim for this project is to create a replacement for the existing ORC
Runtime that currently resides in `llvm-project/compiler-rt/lib/orc`. The new
project will provide a superset of the original features, and the old runtime
will be removed once the new runtime is sufficiently developed.
See discussion at
https://discourse.llvm.org/t/rfc-move-orc-executor-support-into-top-level-project/81049
The CMake flag has been on by default for a month without any issues.
This makes the feature support in LLVM unconditional (but does not
enable the feature by default).
Judging from the reaction to
https://github.com/llvm/llvm-project/pull/152302, we are not ready to
make this a fatal error.
Remove the specific version number, and update the libc message to match
the others' wording.
Add option to `opt` to run the `ProfileInjectorPass` before the passes opt would run, and then `ProfileVerifierPass` after. This will then be a mode in which we run tests on a specialized buildbot, with the goal of finding passes that drop (and, later, corrupt) profile information.
## Purpose
This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `llvm-c` interface with a
new `LLVM_C_ABI` annotation, which behaves like the `LLVM_ABI`. This
annotation currently has no meaningful impact on the LLVM build;
however, it is a prerequisite to support an LLVM Windows DLL (shared
library) build.
## Overview
1. Add a new `llvm-c/Visibility.h` header file that defines a new
`LLVM_C_ABI` macro. The macro resolves to the proper DLL export/import
annotation on Windows and a "default" visibility annotation elsewhere.
2. Add a new `LLVM_ENABLE_LLVM_C_EXPORT_ANNOTATIONS` `#cmakedefine` that
is used to gate the definition of `LLVM_C_ABI`.
3. Remove the existing `LLVM_C_ABI` definition from
`llvm/Support/Compiler.h`. Update the small number of `LLVM_C_ABI`
references to get it from the new `llvm-c/Visibility.h` header.
4. Code-mod annotate the public `llvm-c` interface using the [Interface
Definition Scanner (IDS)](https://github.com/compnerd/ids) tool.
5. Format the changes with `clang-format`.
## Background
This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).
## Validation
Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:
- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
- Darwin with Clang
Set LLVM_EXPERIMENTAL_KEY_INSTRUCTIONS=ON by default. This enables
support for Key Instructions in LLVM by default, it does not enable the
feature by default.
This does have an affect on compile time, which looks to have mostly
been "paid for" (if that argument stands) by my PR #143399.
The RFC for this removal can be found at:
https://discourse.llvm.org/t/rfc-removing-pstl/86807
Note, libc++ still supports PSTL. That support is integrated directly
into the libc++ source tree.
There is no release note for this removal because it's not really clear
that this was user-facing facilities or where such a release note should
live.
## Purpose
Simplify the logic used to define `LLVM_ABI` and related macros,
eliminate the `LLVM_ABI_FRIEND` macro, and update the `LLVM_ABI` macro
to always resolve to `__attribute__((visibility("default")))` when
building LLVM as a shared library for ELF or Mach-O targets.
## Background
Previously, `LLVM_ABI` was defined to the C++ style attribute
`[[gnu::visibility("default")]]` when compiling with gcc, which has more
restrictions on its placement. Of note, the C++ style attributes cannot
decorate `friend` functions and must not appear after `extern` on
variable declarations.
Documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).
## Overview
- Define a new CMake config value,
`LLVM_ENABLE_LLVM_EXPORT_ANNOTATIONS`, which is implicitly set whenever
`LLVM_BUILD_LLVM_DYLIB`, `LLVM_BUILD_SHARED_LIBS`, or
`LLVM_ENABLE_PLUGINS` is set. Add it as a `#cmakedefine` to
llvm-config.h so its definition is available to projects building
against LLVM as required so clients see `__declspec(dllimport)` on
Windows.
- Gate the `LLVM_ABI` macro definitions in Compiler.h behind the new
`LLVM_ENABLE_LLVM_EXPORT_ANNOTATIONS` definition. This is
simpler/cleaner, but should be equivalent to the previous logic.
- Maintain `LLVM_BUILD_STATIC` as an override to be used by specific
targets that don't want to build against the DLL/shared library, such as
tablegen.
- For ELF and Mach-O targets, directly define `LLVM_ABI` as
`__attribute__((visibility("default")))` instead of
`LLVM_ATTRIBUTE_VISIBILITY_DEFAULT`, which resolves to C++ style
`[[gnu::visibility("default")]]` when compiling with gcc.
- Remove the `LLVM_ABI_FRIEND` macro and replace all usages of it with
`LLVM_ABI`.
- Update the documentation for exporting friend functions to no longer
reference `LLVM_ABI_FRIEND`.
## Validation
- Built as static lib with clang and gcc on Linux.
- Built as static with clang-cl and MSVC on Windows.
- Built as shared lib with clang and gcc on Linux (+ additional local
changes not yet merged).
- Built as DLL with clang-cl and MSVC on Windows (+ additional local
changes not yet merged).
---------
Co-authored-by: SquallATF <squallatf@gmail.com>
This patch fixes an issue where the __trampoline_setup symbol is missing
with some programs compiled with flang. This symbol is present only in
compiler-rt and not in libgcc. This patch adds compiler-rt to the link
line after libgcc if libgcc is being used, so that only this symbol will
be picked from compiler-rt.
Fixes#141147
This patch is part of a series that adds origin-tracking to the debugify
source location coverage checks, allowing us to report symbolized stack
traces of the point where missing source locations appear.
This patch adds the configuration options needed to enable this feature,
in the form of a new CMake option that enables a flag in
`llvm-config.h`; this is not an entirely new CMake flag, but a new
option, `COVERAGE_AND_ORIGIN`, for the existing flag
`LLVM_ENABLE_DEBUGLOC_COVERAGE_TRACKING`. This patch contains
documentation, but no actual implementation for the flag itself.
This is a cli tool to that tests the conformance of LLVM's mustache
implementation against the public Mustache spec, hosted at
https://github.com/mustache/spec. This is a revised version of the
patches in #111487.
Co-authored-by: Peter Chou <peter.chou@mail.utoronto.ca>
This commit deprecates the use of LLVM_ENABLE_PROJECTS in favour of
LLVM_ENABLE_RUNTIMES when building libclc.
Alternatively, using -DLLVM_RUNTIME_TARGETS=<triple> combined with
-DRUNTIMES_<triple>_LLVM_ENABLE_RUNTIMES=libclc also gets pretty far but
fails due to zlib problems building the LLVM utility 'prepare_builtins'.
I'm not sure what's going on there but I don't think it's required at
this stage. More work would be required to support that option.
This does nothing to change how the host tools are found in order to be
used to actually build the libclc libraries.
Note that under such a configuration the final libclc builtin libraries
are placed in `<build>/runtimes/runtimes-bins/libclc/`, which differs
from a non-runtimes build. The installation location remains the same.
Fixes#124013.
Many targets have already migrated to the per-target runtime directory
layout, which is generally preferred. For AIX however, we are currently
using per-target runtime directories by default for some runtimes (i.e.
`flang-rt`) but not others. This change makes things consistent for
other runtimes (most primarily `compiler-rt`) as well, adopting the
layout uniformly for the AIX target.
This change also normalizes the triple used for building compiler-rt to
remove any OS version number, as there is currently no need to version
the runtimes this way and the driver code doesn't expect this anyhow.
This is no longer necessary, and results in an inconvenient define of
`i386` on i386 Cygwin targets which breaks compiling
llvm/include/llvm/ExecutionEngine/JITLink/i386.h.
Signed-off-by: Jeremy Drake <github@jdrake.com>
Precompiling larger headers can save a lot of compile time across
various compilation units.
For the time being, disable precompiled headers for ccache builds on Windows
due to issues with reliably passing the appropriate options to ccache.
Selected compile time & memory improvements are as follows:
flang/lib/Parser/Fortran-parsers.cpp:
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:47.31 -> 0:41.68
Maximum resident set size (kbytes): 2062140 -> 1745584
flang/lib/Lower/Bridge.cpp:
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:19.16 -> 0:45.86
Maximum resident set size (kbytes): 3849144 -> 2443476
flang/lib/Lower/PFTBuilder.cpp
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:29.24 -> 1:00.99
Maximum resident set size (kbytes): 4218368 -> 2923128
flang/lib/Lower/Allocatable.cpp
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:53.03 -> 0:22.50
Maximum resident set size (kbytes): 3092840 -> 2116908
flang/lib/Semantics/Semantics.cpp
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:18.75 -> 1:00.20
Maximum resident set size (kbytes): 3527744 -> 2545308
While the newly added precompiled headers are as follows:
Parser:
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:09.62
Maximum resident set size (kbytes): 1034608
Lower:
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:41.33
Maximum resident set size (kbytes): 3615240
Semantics:
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:26.69
Maximum resident set size (kbytes): 2403776
---------
Signed-off-by: Kajetan Puchalski <kajetan.puchalski@arm.com>
This reverts commit 27539c3f903be26c487703943d3c27d45d4542b2. Retry
with new buildbot configuration after master restart.
Original message:
Remove the FLANG_INCLUDE_RUNTIME option which was replaced by
LLVM_ENABLE_RUNTIMES=flang-rt.
The FLANG_INCLUDE_RUNTIME option was added in #122336 which disables the
non-runtimes build instructions for the Flang runtime so they do not
conflict with the LLVM_ENABLE_RUNTIMES=flang-rt option added in #110217.
In order to not maintain multiple build instructions for the same thing,
this PR completely removes the old build instructions (effectively
forcing FLANG_INCLUDE_RUNTIME=OFF).
As per discussion in
https://discourse.llvm.org/t/buildbot-changes-with-llvm-enable-runtimes-flang-rt/83571/2
we now implicitly add LLVM_ENABLE_RUNTIMES=flang-rt whenever Flang is
compiled in a bootstrapping (non-standalone) build. Because it is
possible to build Flang-RT separately, this behavior can be disabled
using `-DFLANG_ENABLE_FLANG_RT=OFF`. Also see the discussion an
implicitly adding runtimes/projects in #123964.
The `llvm-headers` target wasn't depending on the generated TargetParser
headers, so they'd be flakily installed or not installed depending on
which order the build steps ran in. Add an explicit dependency to fix
this, and switch to a single `target_parser_gen` target to mirror the
pattern used by `intrinsics_gen` (which also fixes a few other missing
dependencies). Switch `llvm-headers` to use `add_dependencies` instead
of `DEPENDS` for the tablegen dependencies as well, since `DEPENDS` is
only intended for creating a file-level dependency on the output of an
`add_custom_command` in the same CMakeLists.txt (see `DEPENDS` under
https://cmake.org/cmake/help/latest/command/add_custom_target.html).
Summary:
These are compiler runtimes are currently have weird support for
projects / runtimes. We should depcrate this to where the only expected
configuration is via a runtimes build. If the user wants a custom setup
they can still use the standalone build.
I remember there were some concerens around the OpenMP module file for
`flang`. Were those resolved?
Fixes: https://github.com/llvm/llvm-project/issues/124014
Only the host OS matters for how to interact with ccache, not the target
OS that we may be cross compiling for.
This mistake seems to have been present all since support for ccache on
Windows was added in
a4425cc9146059618b3b7e927639b60a7c3301bc.
In order for precompiled headers to work with ccache, a specific flag
needs to be passed to the compiler and ccache's sloppiness configuration
option needs to be set appropriately.
Due to issues with configuring CMake on certain Windows platforms, set
the required ccache option only on non-Windows systems for the time
being.
-----
Signed-off-by: Kajetan Puchalski <kajetan.puchalski@arm.com>
When enabling or disabling a target we typically need to rebuild most
of LLVM because of the change to the values of the LLVM_HAS_*_TARGET
macros in llvm-config.h, which is included by most of the code, but
are unused by LLVM itself. To avoid this, move the LLVM_HAS_*_TARGET
macros to a separate header, Targets.h.
Update the only in-tree user of the macros (MLIR) to refer to the new
header. I expect that out-of-tree users will detect the change either
at compile time if they build with -Wundef, or at runtime. As far as
I can tell, the usage of these macros is rare in out-of-tree projects,
I found no out-of-tree users in projects indexed by Debian code search
[1], and one user [2] in projects indexed by GitHub code search [3]
(excluding forks of LLVM).
[1] https://codesearch.debian.net/search?q=%23.*LLVM_HAS_.*_TARGET&literal=0
[2] 238706b12b/lib/gc/Target/LLVM/XeVM/Target.cpp (L72)
[3] https://github.com/search?q=%2F%23.*LLVM_HAS_.*_TARGET%2F&type=code
Reviewers: nico, grypp, mstorsjo, MaskRay
Reviewed By: MaskRay
Pull Request: https://github.com/llvm/llvm-project/pull/136388
Since ccache 4.8, it is possible to pass configuration options directly
to ccache on the command line as opposed to through environment
variables.
This is the intended way for CMake to configure ccache, as described on
the GitHub wiki for the project:
https://github.com/ccache/ccache/wiki/CMake
This should allow for uniform ccache configuration that does not rely on
platform-specific environment setup.
Rework the way ccache is configured by LLVM accordingly.
---------
Signed-off-by: Kajetan Puchalski <kajetan.puchalski@arm.com>
Using precompiled headers with ccache requires special accommodations.
Add the required ccache options, clang and gcc compiler flags to CMake.
Refactor ccache configuration to pass options directly on the command line for versions of ccache that support it.
---------
Signed-off-by: Kajetan Puchalski <kajetan.puchalski@arm.com>
This patch refactors the generate_test_report script, namely turning it
into a proper library, and pulling the script/unittests out into
separate files, as is standard with most python scripts. The main
purpose of this is to enable reusing the library for the new Github
premerge.
Reviewers: tstellar, DavidSpickett, Keenuts, lnihlen
Reviewed By: DavidSpickett
Pull Request: https://github.com/llvm/llvm-project/pull/133196
The production buildbot master apparently has not yet been restarted
since https://github.com/llvm/llvm-zorg/pull/393 landed.
This reverts commit 96d1baedefc3581b53bc4389bb171760bec6f191.
Remove the FLANG_INCLUDE_RUNTIME option which was replaced by
LLVM_ENABLE_RUNTIMES=flang-rt.
The FLANG_INCLUDE_RUNTIME option was added in #122336 which disables the
non-runtimes build instructions for the Flang runtime so they do not
conflict with the LLVM_ENABLE_RUNTIMES=flang-rt option added in #110217.
In order to not maintain multiple build instructions for the same thing,
this PR completely removes the old build instructions (effectively
forcing FLANG_INCLUDE_RUNTIME=OFF).
As per discussion in
https://discourse.llvm.org/t/buildbot-changes-with-llvm-enable-runtimes-flang-rt/83571/2
we now implicitly add LLVM_ENABLE_RUNTIMES=flang-rt whenever Flang is
compiled in a bootstrapping (non-standalone) build. Because it is
possible to build Flang-RT separately, this behavior can be disabled
using `-DFLANG_ENABLE_FLANG_RT=OFF`. Also see the discussion an
implicitly adding runtimes/projects in #123964.
Clang is required to compile Flang. Instead of erroring-out if Clang is
enabled, for convinience implicitly add it to `LLVM_ENABLE_PROJECTS`,
consistent with how the MLIR dependency is handled.
This is motivatated by the discussion on whether flang-rt shoud be enabled implicitly
(https://discourse.llvm.org/t/buildbot-changes-with-llvm-enable-runtimes-flang-rt/83571/2).
Since the answer was yet, clang would have been the only exception of not being
enabled implicitly. Fixed with this commit.
Summary:
There were a few issues with the first one, leading to some errors and
warnings. Most importantly, this was building on MSVC which isn't
supported.
Summary:
These tools `amdhsa-loader` and `nvptx-loader` are used to execute unit
tests directly on the GPU. We use this for `libc` and `libcxx` unit
tests as well as general GPU experimentation. It looks like this.
```console
> clang++ main.cpp --target=amdgcn-amd-amdhsa -mcpu=native -flto -lc ./lib/amdgcn-amd-amdhsa/crt1.o
> llvm-gpu-loader a.out
Hello World!
```
Currently these are a part of the `libc` project, but this creates
issues as `libc` itself depends on them to run tests. Right now we get
around this by force-including the `libc` project prior to running the
runtimes build so that this dependency can be built first. We should
instead just make this a simple LLVM tool so it's always available.
This has the effect of installing these by default now instead of just
when `libc` was enabled, but they should be relatively small. Right now
this only supports a 'static' configuration. That is, we locate the CUDA
and HSA dependencies at LLVM compile time. In the future we should be
able to provide this by default using `dlopen` and some API.
I don't know if it's required to reformat all of these names since they
used the `libc` naming convention so I just left it for now.
Key Instructions will start development behind a compile time flag to avoid
passing on the increased memory usage to all debug builds. We're working on
improving DILocation memory characteristics simultaneously; once that work lands
we can remove `EXPERIMENTAL_KEY_INSTRUCTIONS`.
This patch doesn't add any code, it's just so we can get the SIE buildbot
building with the new option right away.
When building in tree clang without having `-pthread` we get a bunch of
`Assertion failed: FD != kInvalidFile && "Invalid or inactive file
descriptor"` when testing check-clang.
Details:
- Previously, we used the LLVM_BUILD_TELEMETRY flag to control whether
any Telemetry code will be built. This has proven to cause more nuisance
to both users of the Telemetry and any further extension of it. (Eg., we
needed to put #ifdef around caller/user code)
- So the new approach is to:
+ Remove this flag and introduce LLVM_ENABLE_TELEMETRY which would be
true by default.
+ If LLVM_ENABLE_TELEMETRY is set to FALSE (at buildtime), the library
would still be built BUT Telemetry cannot be enabled. And no data can be
collected.
The benefit of this is that it simplifies user (and extension) code
since we just need to put the check on Config::EnableTelemetry. Besides,
the Telemetry library itself is very small, hence the additional code to
be built would not cause any difference in build performance.
---------
Co-authored-by: Pavel Labath <pavel@labath.sk>
Extract Flang's runtime library to use the LLVM_ENABLE_RUNTIME
mechanism. It will only become active when
`LLVM_ENABLE_RUNTIMES=flang-rt` is used, which also changes the
`FLANG_INCLUDE_RUNTIME` to `OFF` so the old runtime build rules do not
conflict. This also means that unless `LLVM_ENABLE_RUNTIMES=flang-rt` is
passed, nothing changes with the current build process.
Motivation:
* Consistency with LLVM's other runtime libraries (compiler-rt, libc,
libcxx, openmp offload, ...)
* Allows compiling the runtime for multiple targets at once using the
LLVM_RUNTIME_TARGETS configuration options
* Installs the runtime into the compiler's per-target resource directory
so it can be automatically found even when cross-compiling
Also see RFC discussion at
https://discourse.llvm.org/t/rfc-use-llvm-enable-runtimes-for-flangs-runtime/80826
Add a CMake flag (LLVM_BUILD_TELEMETRY) to disable building the
telemetry framework. The flag being enabled does *not* mean that
telemetry is being collected, it merely means we're building the generic
telemetry framework. Hence the flag is enabled by default.
Motivated by this Discourse thread:
https://discourse.llvm.org/t/how-to-disable-building-llvm-clang-telemetry/84305
