This PR is to improve the driver code to build `flang-rt` path by
re-using the logic and code of `compiler-rt`.
1. Moved `addFortranRuntimeLibraryPath` and `addFortranRuntimeLibs` to
`ToolChain.h` and made them virtual so that they can be overridden if
customization is needed. The current implementation of those two
procedures is moved to `ToolChain.cpp` as the base implementation to
default to.
2. Both AIX and PPCLinux now override `addFortranRuntimeLibs`.
The overriding function of `addFortranRuntimeLibs` for both AIX and
PPCLinux calls `getCompilerRTArgString` => `getCompilerRT` =>
`buildCompilerRTBasename` to get the path to `flang-rt`. This code
handles `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` setting. As shown in
`PPCLinux.cpp`, `FT_static` is the default. If not found, it will search
and build for `FT_shared`. To differentiate `flang-rt` from `clang-rt`,
a boolean flag `IsFortran` is passed to the chain of functions in order
to reach `buildCompilerRTBasename`.
Previously, alignment option was passed to multilib selection logic only
when -mno-unaligned-access was explicitly specified on the command line.
Now this change ensure both -mno-unaligned-access and -munaligned-access
are passed to the multilib selection logic, which now also considers the
target architecture when determining alignment access policy.
In the wake of discussion in PR #131200 and internal discussion after,
we will add support for `LLVM_ENABLE_PER_TARGET_RUNTIME=ON` for AIX
instead of disable it. I already reverted the change in PR #131200.
The default value of the option is still OFF on AIX.
Add an option similar to the -qtarget option in XL to allow the user to
say they want to be able to run the generated program on an older
version of the LE environment. This option will do two things:
- set the `__TARGET_LIBS` macro so the system headers exclude newer
interfaces when targeting older environments
- set the arch level to match the minimum arch level for that older
version of LE. It doesn't happen right now since all of the supported LE
versions have a the same minimum ach level. So the option doesn't change
this yet.
The user can specify three different kinds of arguments:
1. -mzos-target=zosv*V*r*R* - where V & R are the version and release
2. -mzos-target=0x4vrrmmmm - v, r, m, p are the hex values for the
version, release, and modlevel
3. -mzos-target=current - uses the latest version of LE the system
headers have support for
Summary:
Currently the `-Xarch` argument needs to re-parse the option, which goes
through every single registered argument. This causes errors when trying
to pass `-O1` through it because it thinks it's a DXC option. This patch
changes the behavior to only allow `clang` options. Concievably we could
detect the driver mode to make this more robust, but I don't know if
there are other users for this.
Fixes: https://github.com/llvm/llvm-project/issues/110325
Summary:
Currently, `-Xarch_` is handled specially between different toolchains,
(i.e. Mach-O).
This patch unifies the handling so that it can be used generically.
The main benefit here is that we now have a more generic version of
`-Xopenmp-target=`, which should probably just be deprecated.
Additionally, it allows us to specially pass arguments to different
architectures for offloading.
This patch is done in preparation for making selecting offloading
toolchains more generic, this will be helpful while people are moving
toward compile jobs that include multiple toolchains (SPIR-V, AMDGCN,
NVPTX).
In the discussion around #116792, @rjmccall mentioned that ARCMigrate
has been obsoleted and that we could go ahead and remove it from Clang,
so this patch does just that.
This patch is the second step to extend the current multilib system to
support the selection of library variants which do not correspond to
existing command-line options.
Proposal can be found in
https://discourse.llvm.org/t/rfc-multilib-custom-flags/81058
The multilib mechanism supports libraries that target code generation or
language options such as --target, -mcpu, -mfpu, -mbranch-protection.
However, some library variants are particular to features that do not
correspond to any command-line options. Examples include variants for
multithreading and semihosting.
This work introduces a way to instruct the multilib system to consider
these features in library selection.
The driver must be informed about the multilib custom flags with a new
command-line option.
```
-fmultilib-flag=C
```
Where the grammar for C is:
```
C -> option
option -> multithreaded | no-multithreaded | io-none | io-semihosting | io-linux-syscalls | ...
```
There must be one option instance for each flag specified:
```
-fmultilib-flag=multithreaded -fmultilib-flag=io-semihosting
```
Contradictory options are untied by *last one wins*.
These options are to be used exclusively by the multilib mechanism in
the Clang driver. Hence they are not forwarded to the compiler frontend.
Introduces the SYCL based toolchain and initial toolchain construction
when using the '-fsycl' option. This option will enable SYCL based
offloading, creating a SPIR-V based IR file packaged into the compiled
host object.
This includes early support for creating the host/device object using
the new offloading model. The device object is created using the
spir64-unknown-unknown target triple.
New/Updated Options:
-fsycl Enables SYCL offloading for host and device
-fsycl-device-only
Enables device only compilation for SYCL
-fsycl-host-only
Enables host only compilation for SYCL
RFC Reference:
https://discourse.llvm.org/t/rfc-sycl-driver-enhancements/74092
This is a reland of: https://github.com/llvm/llvm-project/pull/107493
Introduces the SYCL based toolchain and initial toolchain construction
when using the '-fsycl' option. This option will enable SYCL based
offloading, creating a SPIR-V based IR file packaged into the compiled
host object.
This includes early support for creating the host/device object using
the new offloading model. The device object is created using the
spir64-unknown-unknown target triple.
New/Updated Options:
-fsycl Enables SYCL offloading for host and device
-fsycl-device-only
Enables device only compilation for SYCL
-fsycl-host-only
Enables host only compilation for SYCL
RFC Reference:
https://discourse.llvm.org/t/rfc-sycl-driver-enhancements/74092
This removes the temporary ban on mixing AMDGCN flavoured SPIR-V and
concrete targets (e.g. `gfx900`) in the same HIPAMD compilation. This is
done primarily by tweaking the effective / observable triple when the
target is `amdgcnspirv`, which seamlessly composes with the existing
infra. The test is stolen from #75357.
In https://github.com/llvm/llvm-project/pull/109837, it sets a global
variable(`PGOInstrumentColdFunctionOnly`) in PassBuilderPipelines.cpp
which introduced a data race detected by TSan. To fix this, I decouple
the flag setting, the flags are now set
separately(`instrument-cold-function-only-path` is required to be used
with `--pgo-instrument-cold-function-only`).
PR https://github.com/llvm/llvm-project/pull/111976 was enabling the
tests updated in the PR to run on all systems. We found a few didn't run
on z/OS. I tracked the problem down to:
1. the ExecuteToolChainProgram() function wasn't passing the executable
name as the first arg. That was causing exec on z/OS to fail.
2. the temp file needs to be a text file so codepage conversion happens.
This patch adds support for cold function coverage instrumentation based
on sampling PGO counts. The major motivation is to detect dead functions
for the services that are optimized with sampling PGO. If a function is
covered by sampling profile count (e.g., those with an entry count > 0),
we choose to skip instrumenting those functions, which significantly
reduces the instrumentation overhead.
More details about the implementation and flags:
- Added a flag `--pgo-instrument-cold-function-only` in
`PGOInstrumentation.cpp` as the main switch to control skipping the
instrumentation.
- Built the extra instrumentation passes(a bundle of passes in
`addPGOInstrPasses`) under sampling PGO pipeline. This is controlled by
`--instrument-cold-function-only-path` flag.
- Added a driver flag `-fprofile-generate-cold-function-coverage`:
- 1) Config the flags in one place, i,e. adding
`--instrument-cold-function-only-path=<...>` and
`--pgo-function-entry-coverage`. Note that the instrumentation file path
is passed through `--instrument-sample-cold-function-path`, because we
cannot use the `PGOOptions.ProfileFile` as it's already used by
`-fprofile-sample-use=<...>`.
- 2) makes linker to link `compiler_rt.profile` lib(see
[ToolChain.cpp#L1125-L1131](https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChain.cpp#L1125-L1131)
).
- Added a flag(`--pgo-cold-instrument-entry-threshold`) to config entry
count to determine cold function.
Overall, the full command is like:
```
clang++ -O2 -fprofile-generate-cold-function-coverage=<...> -fprofile-sample-use=<...> code.cc -o code
```
This does a global rename from `flang-new` to `flang`. I also
removed/changed any TODOs that I found related to making this change.
---------
Co-authored-by: H. Vetinari <h.vetinari@gmx.com>
Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
PR #102521, which landed as 1ea0865dd6fa, implemented
`CLANG_TOOLCHAIN_PROGRAM_TIMEOUT`, but the logic is obviously wrong.
If the user-specified value is negative, it should become zero to mean
infinite. Otherwise, it should be left as is. Thus, use `std::max`
not `std::min`. This obvious fixup doesn't seem worth another pull
request.
This change modifies -ffp-model=fast to select options that more closely
match -funsafe-math-optimizations, and introduces a new model,
-ffp-model=aggressive which matches the existing behavior (except for a
minor change in the fp-contract behavior).
The primary motivation for this change is to make -ffp-model=fast more
user friendly, particularly in light of LLVM's aggressive optimizations
when -fno-honor-nans and -fno-honor-infinites are used.
This was previously proposed here:
https://discourse.llvm.org/t/making-ffp-model-fast-more-user-friendly/78402
This changes the bare-metal driver logic such that it _always_ tries
multilib.yaml if it exists, and it falls back to the hardwired/default
RISC-V multilib selection only if a multilib.yaml doesn't exist. In
contrast, the current behavior is that RISC-V can never use
multilib.yaml, but other targets will try it if it exists.
The flags `-march=` and `-mabi=` are exposed for multilib.yaml to match
on. There is no attempt to help YAML file creators to duplicate the
existing hard-wired multilib reuse logic -- they will have to implement
it using `Mappings`.
This should be backwards-compatible with existing sysroots, as
multilib.yaml was previously never used for RISC-V, and the behavior
doesn't change after this PR if the file doesn't exist.
When working on very busy systems, check-offload frequently fails many
tests with this diagnostic:
```
clang: error: cannot determine amdgcn architecture: /tmp/llvm/build/bin/amdgpu-arch: Child timed out: ; consider passing it via '-march'
```
This patch accepts the environment variable
`CLANG_TOOLCHAIN_PROGRAM_TIMEOUT` to set the timeout. It also increases
the timeout from 10 to 60 seconds.
Support for this was added back in 2016
(https://reviews.llvm.org/D27499), but never enabled in the driver.
Since then, it's been possible to enable this with an arm triple and the
-mthumb option, but not with a thumb triple.
This also caused -fsanitise=cfi to enable cfi-icall for arm triple but
not thumb triples, which caused spurious sanitiser failures if mixing
the two ISAs in one program.
When `pauthtest` is either passed as environment part of AArch64 Linux
triple
or passed via `-mabi=`, enable the following ptrauth flags:
- `intrinsics`;
- `calls`;
- `returns`;
- `auth-traps`;
- `vtable-pointer-address-discrimination`;
- `vtable-pointer-type-discrimination`;
- `init-fini`.
Some related stuff is still subject to change, and the ABI itself might
be changed, so end users are not expected to use this and the ABI name
has 'test' suffix.
If `-mabi=pauthtest` option is used, it's normalized to effective
triple.
When the environment part of the effective triple is `pauthtest`, try
to use `aarch64-linux-pauthtest` as multilib directory.
The following is not supported:
- combination of `pauthtest` ABI with any branch protection scheme
except BTI;
- explicit set of environment part of the triple to a value different
from `pauthtest` in combination with `-mabi=pauthtest`;
- usage on non-Linux OS.
---------
Co-authored-by: Anatoly Trosinenko <atrosinenko@accesssoftek.com>
In a multilib setting, if you compile with a command line such as `clang
--target=aarch64-none-elf -march=armv8.9-a+rcpc3`,
`getAArch64MultilibFlags` returns an ill-formed string containing two
consecutive `+` signs, of the form `...+rcpc++rcpc3+...`, causing later
stages of multilib selection to get confused.
The `++` arises from the entry in `AArch64::Extensions` for the
SubtargetFeature `rcpc-immo`, which is a dependency of the `rcpc3`
SubtargetFeature, but doesn't have an _extension_ name for the purposes
of the `-march=foo+bar` option. So its `UserVisibleName` field is the
empty string.
To fix this, I've excluded extensions from consideration in
`getAArch64MultilibFlags` if they have an empty `UserVisibleName`. Since
the input to this function is not derived from a completely general set
of SubtargetFeatures, but from a set that has only just been converted
_from_ a clang driver command line, the only extensions skipped by this
check should be cases like this one, where the anonymous extension was
only included because it was a dependency of one mentioned explicitly.
I've also made the analogous change in `getARMMultilibFlags`. I don't
think it's necessary right now, because the architecture extensions for
ARM (defined in `ARMTargetParser.def` rather than Tablegen) don't
include any anonymous ones. But it seems sensible to add the check
anyway, in case future refactoring introduces anonymous array elements
in the same way that AArch64 did, and also in case someone writes a
function for another platform by using either of these as example code.
We want to support using a complete Clang/LLVM toolchain that includes
LLVM libc and libc++ for baremetal targets. To do so, we need the driver
to add the necessary include paths.
This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that are enabled for the
target specified by the combination of `--target`/`-march`/`-mcpu`
values.
The goal of the this option is both to enable the manual inspection of
the enabled extensions by users and to enhance the testability of
architecture versions and CPU targets implemented in the compiler.
As part of this change, a new field for `FEAT_*` architecture feature
names was added to the TableGen entries. The output of the existing
`--print-supported-extensions` option was updated accordingly to show
these in a separate column.
This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that are enabled for the
target specified by the combination of `--target`/`-march`/`-mcpu`
values.
The goal of the this option is both to enable the manual inspection of
the enabled extensions by users and to enhance the testability of
architecture versions and CPU targets implemented in the compiler.
As part of this change, a new field for `FEAT_*` architecture feature
names was added to the TableGen entries. The output of the existing
`--print-supported-extensions` option was updated accordingly to show
these in a separate column.
Summary:
The utilities `nvptx-arch` and `amdgpu-arch` are used to support
`--offload-arch=native` among other utilities in clang. However, these
rely on the GPU drivers to query the features. In certain cases these
drivers can become locked up, which will lead to indefinate hangs on any
compiler jobs running in the meantime.
This patch adds a ten second timeout period for these utilities before
it kills the job and errors out.
This change cleans up the clang driver handling of umbrella options like
-ffast-math, -funsafe-math-optimizations, and -ffp-model, and aligns the
behavior of -ffp-model=fast with -ffast-math with regard to the linking
of crtfastmath.o.
We agreed in a previous review that the fast-math options should not
attempt to change the -fdenormal-fp-math option, which is inherently
target-specific.
The clang user's manual claims that -ffp-model=fast "behaves identically
to specifying both -ffast-math and -ffp-contract=fast." Since
-ffast-math causes crtfastmath.o to be linked if it is available, that should
also happen with -ffp-model=fast.
I am going to be proposing further changes to -ffp-model=fast,
decoupling it from -ffast-math and introducing a new
-ffp-model=aggressive that matches the current behavior, but I wanted
to solidfy the current behavior before I do that.
This fixes https://github.com/llvm/llvm-project/issues/57589, and aligns
Clang with the behavior of current versions of gcc. There is a new
option, -mdaz-ftz, to control the linking of the file that sets FTZ/DAZ
on startup, and this flag is on by default if -ffast-math is present and
-shared isn't.
This also partially reverts fa7cd549d60 in that it disables the attempt
to set the IR denormal-fp-math attribute based on whether or not
-ffast-math is applied as it is insufficiently reliable.
Follow-up to #81037.
ToolChain::LibraryPaths holds the new compiler-rt library directory
(e.g. `/tmp/Debug/lib/clang/19/lib/x86_64-unknown-linux-gnu`). However,
it might be empty when the directory does not exist (due to the `if
(getVFS().exists(P))` change in https://reviews.llvm.org/D158475).
If neither the old/new compiler-rt library directories exists, we would
suggest the undesired old compiler-rt file name:
```
% /tmp/Debug/bin/clang++ a.cc -fsanitize=memory -o a
ld.lld: error: cannot open /tmp/Debug/lib/clang/19/lib/linux/libclang_rt.msan-x86_64.a: No such file or directory
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
```
With this change, we will correctly suggest the new compiler-rt file name.
Fix#87150
Pull Request: https://github.com/llvm/llvm-project/pull/87866
This reverts commit ccdebbae4d77d3efc236af92c22941de5d437e01.
Causes test failures in the presence of Android runtime libraries in resource-dir.
See comments on https://github.com/llvm/llvm-project/pull/87866.
Follow-up to #81037.
ToolChain::LibraryPaths holds the new compiler-rt library directory
(e.g. `/tmp/Debug/lib/clang/19/lib/x86_64-unknown-linux-gnu`). However,
it might be empty when the directory does not exist (due to the `if
(getVFS().exists(P))` change in https://reviews.llvm.org/D158475).
If neither the old/new compiler-rt library directories exists, we would
suggest the undesired old compiler-rt file name:
```
% /tmp/Debug/bin/clang++ a.cc -fsanitize=memory -o a
ld.lld: error: cannot open /tmp/Debug/lib/clang/19/lib/linux/libclang_rt.msan-x86_64.a: No such file or directory
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
```
With this change, we will correctly suggest the new compiler-rt file name.
Fix#87150
Pull Request: https://github.com/llvm/llvm-project/pull/87866
This reverts commit bbc0f99f3bc96f1db16f649fc21dd18e5b0918f6
(https://reviews.llvm.org/D157663).
With this change, `-g` for the next major release 19.1 will generate
R_RISCV_SET_ULEB128/R_RISCV_SUB_ULEB128 relocations, which require
lld>=18 or binutils>=2.41.
binutils 2.41 is relatively new, but GCC has been producing
R_RISCV_SET_ULEB128/R_RISCV_SUB_ULEB128 for some time now.
BSD, Linux, and z/OS enable `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` by
default.
When a compiler-rt library is not found, we currently report an
incorrect filename `libclang_rt.XXX-$arch.a`
```
% /tmp/Debug/bin/clang++ a.cc -fsanitize=address -o a
ld.lld: error: cannot open /tmp/Debug/lib/clang/19/lib/linux/libclang_rt.asan-x86_64.a: No such file or directory
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
```
With this change, we will correctly report:
```
% /tmp/Debug/bin/clang++ a.cc -fsanitize=address -o a
ld.lld: error: cannot open /tmp/Debug/lib/clang/19/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.a: No such file or directory
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
```
Link: https://discourse.llvm.org/t/runtime-directory-fallback/76860
The deduced "-march=" option always started with aarch64, which is not a
valid value. There was also no way to distinguish between armv8-r and
armv8-a. After this commit, the deduced "-march=" option will start with
greatest available "armv*-a" value or "armv8-r".
Installapi has important distinctions when compared to the clang driver,
so much that, it doesn't make much sense to try to integrate into it.
This patch partially reverts the CC1 action & driver support to replace
with its own driver as a clang tool.
For distribution, we could use `LLVM_TOOL_LLVM_DRIVER_BUILD` mechanism
for integrating the functionality into clang such that the toolchain
size is less impacted.
This introduces a basic outline of installapi as a clang driver option.
It captures relevant information as cc1 args, which are common arguments
already passed to the linker to encode into TBD file outputs. This is
effectively an upstream for what already exists as `tapi installapi` in
Xcode toolchains, but directly in Clang. This patch does not handle any
AST traversing on input yet.
InstallAPI is broadly an operation that takes a series of header files
that represent a single dynamic library and generates a TBD file out of
it which represents all the linkable symbols and necessary attributes
for statically linking in clients. It is the linkable object in all
Apple SDKs and when building dylibs in Xcode. `clang -installapi` also
will support verification where it compares all the information recorded
for the TBD files against the already built binary, to catch possible
mismatches like when a declaration is missing a definition for an
exported symbol.
