[Multilib] Add -fmultilib-flag command-line option (#110658)

This patch is the second step to extend the current multilib system to
support the selection of library variants which do not correspond

[Multilib] Add -fmultilib-flag command-line option (#110658)

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.

show more ...

[Driver][SYCL] Add initial SYCL offload compilation support (#117268)

Introduces the SYCL based toolchain and initial toolchain construction
when using the '-fsycl' option. This option will enable

[Driver][SYCL] Add initial SYCL offload compilation support (#117268)

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

show more ...

[Driver][OpenMP] Fix OpenMP target-toolchain-option parser (#115375)

## Description

This PR fixes a segmentation fault that occurs when passing options
requiring arguments via `-Xopenmp-target=<

[Driver][OpenMP] Fix OpenMP target-toolchain-option parser (#115375)

## Description

This PR fixes a segmentation fault that occurs when passing options
requiring arguments via `-Xopenmp-target=<triple>`. The issue was that
the function `Driver::getOffloadArchs` did not properly parse the
extracted option, but instead assumed it was valid, leading to a crash
when incomplete arguments were provided.

## Backtrace

```sh
llvm-project/build/bin/clang++ main.cpp -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target=powerpc64le-ibm-linux-gnu -o
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: llvm-project/build/bin/clang++ main.cpp -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target=powerpc64le-ibm-linux-gnu -o
1. Compilation construction
2. Building compilation actions
#0 0x0000562fb21c363b llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (llvm-project/build/bin/clang+++0x392f63b)
#1 0x0000562fb21c0e3c SignalHandler(int) Signals.cpp:0:0
#2 0x00007fcbf6c81420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#3 0x0000562fb1fa5d70 llvm::opt::Option::matches(llvm::opt::OptSpecifier) const (llvm-project/build/bin/clang+++0x3711d70)
#4 0x0000562fb2a78e7d clang::driver::Driver::getOffloadArchs(clang::driver::Compilation&, llvm::opt::DerivedArgList const&, clang::driver::Action::OffloadKind, clang::driver::ToolChain const*, bool) const (llvm-project/build/bin/clang+++0x41e4e7d)
#5 0x0000562fb2a7a9aa clang::driver::Driver::BuildOffloadingActions(clang::driver::Compilation&, llvm::opt::DerivedArgList&, std::pair<clang::driver::types::ID, llvm::opt::Arg const*> const&, clang::driver::Action*) const (.part.1164) Driver.cpp:0:0
#6 0x0000562fb2a7c093 clang::driver::Driver::BuildActions(clang::driver::Compilation&, llvm::opt::DerivedArgList&, llvm::SmallVector<std::pair<clang::driver::types::ID, llvm::opt::Arg const*>, 16u> const&, llvm::SmallVector<clang::driver::Action*, 3u>&) const (llvm-project/build/bin/clang+++0x41e8093)
#7 0x0000562fb2a8395d clang::driver::Driver::BuildCompilation(llvm::ArrayRef<char const*>) (llvm-project/build/bin/clang+++0x41ef95d)
#8 0x0000562faf92684c clang_main(int, char**, llvm::ToolContext const&) (llvm-project/build/bin/clang+++0x109284c)
#9 0x0000562faf826cc6 main (llvm-project/build/bin/clang+++0xf92cc6)
#10 0x00007fcbf6699083 __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:342:3
#11 0x0000562faf923a5e _start (llvm-project/build/bin/clang+++0x108fa5e)
[1] 2628042 segmentation fault (core dumped) main.cpp -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -o
```

show more ...

[Driver] Remove unused includes (NFC) (#116316)

Identified with misc-include-cleaner.

Revert "[Driver][SYCL] Add initial SYCL offload compilation support" (#116381)

Reverts llvm/llvm-project#107493

Failing bots include:
https://lab.llvm.org/buildbot/#/builders/190/builds/9546
ht

Revert "[Driver][SYCL] Add initial SYCL offload compilation support" (#116381)

Reverts llvm/llvm-project#107493

Failing bots include:
https://lab.llvm.org/buildbot/#/builders/190/builds/9546
https://lab.llvm.org/buildbot/#/builders/46/builds/7938

show more ...

[Driver][SYCL] Add initial SYCL offload compilation support (#107493)

Introduces the SYCL based toolchain and initial toolchain construction
when using the '-fsycl' option. This option will enable

[Driver][SYCL] Add initial SYCL offload compilation support (#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

show more ...

Add -mno-unaligned-access and -mbig-endian to ARM and AArch64 multilib flags (#114782)

This adds -mno-unaligned-access and -mbig-endian command line
options to the set of flags used by the multilib

Add -mno-unaligned-access and -mbig-endian to ARM and AArch64 multilib flags (#114782)

This adds -mno-unaligned-access and -mbig-endian command line
options to the set of flags used by the multilib selection for ARM and
AArch64 targets.

show more ...

[clang][Driver][HIP] Add support for mixing AMDGCNSPIRV & concrete `offload-arch`s. (#113509)

This removes the temporary ban on mixing AMDGCN flavoured SPIR-V and
concrete targets (e.g. `gfx900`) i

[clang][Driver][HIP] Add support for mixing AMDGCNSPIRV & concrete `offload-arch`s. (#113509)

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.

show more ...

[InstrPGO] Avoid using global variable to fix potential data race (#114364)

In https://github.com/llvm/llvm-project/pull/109837, it sets a global
variable(`PGOInstrumentColdFunctionOnly`) in PassBu

[InstrPGO] Avoid using global variable to fix potential data race (#114364)

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`).

show more ...

Revert "[InstrPGO] Support cold function coverage instrumentation (#109837)"

This reverts commit e517cfc531886bf6ed64b4e7109bb3141ac7f430.

Pass the executable name as arg[0] when calling ExecuteAndWait() (#114067)

PR https://github.com/llvm/llvm-project/pull/111976 was enabling the
tests updated in the PR to run on all systems. We fou

Pass the executable name as arg[0] when calling ExecuteAndWait() (#114067)

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.

show more ...

[InstrPGO] Support cold function coverage instrumentation (#109837)

This patch adds support for cold function coverage instrumentation based
on sampling PGO counts. The major motivation is to detec

[InstrPGO] Support cold function coverage instrumentation (#109837)

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
```

show more ...

[flang][driver] rename flang-new to flang (#110023)

This does a global rename from `flang-new` to `flang`. I also
removed/changed any TODOs that I found related to making this change.

---------

[flang][driver] rename flang-new to flang (#110023)

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>

show more ...

[AArch64] Pass -mabi option through to multilib (#110874)

Pass the -mabi option through to multilib, so that it can be used for
library selection.

[Clang] Fix CLANG_TOOLCHAIN_PROGRAM_TIMEOUT logic

PR #102521, which landed as 1ea0865dd6fa, implemented
`CLANG_TOOLCHAIN_PROGRAM_TIMEOUT`, but the logic is obviously wrong.
If the user-specified val

[Clang] Fix CLANG_TOOLCHAIN_PROGRAM_TIMEOUT logic

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.

show more ...

[clang][AIX] Fix -print-runtime-dir on AIX (#104806)

Currently the option prints a path to a nonexistent directory with the
full triple, `lib/powerpc64-ibm-aix7.2.0.0`. It should only be
`lib/aix`.

[Driver] Add -mbranch-protection to ARM and AArch64 multilib flags (#106391)

This adds the `-mbranch-protection` command line option to the set of
flags used by the multilib selection for ARM and A

[Driver] Add -mbranch-protection to ARM and AArch64 multilib flags (#106391)

This adds the `-mbranch-protection` command line option to the set of
flags used by the multilib selection for ARM and AArch64 targets.

show more ...

[Driver] Make ffp-model=fast honor non-finite-values, introduce ffp-model=aggressive (#100453)

This change modifies -ffp-model=fast to select options that more closely
match -funsafe-math-optimizat

[Driver] Make ffp-model=fast honor non-finite-values, introduce ffp-model=aggressive (#100453)

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

show more ...

[RISCV] Allow YAML file to control multilib selection (#98856)

This changes the bare-metal driver logic such that it _always_ tries
multilib.yaml if it exists, and it falls back to the hardwired/de

[RISCV] Allow YAML file to control multilib selection (#98856)

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.

show more ...

[Clang] Add env var for nvptx-arch/amdgpu-arch timeout (#102521)

When working on very busy systems, check-offload frequently fails many
tests with this diagnostic:

```
clang: error: cannot dete

[Clang] Add env var for nvptx-arch/amdgpu-arch timeout (#102521)

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.

show more ...

[ARM] Enable cfi-icall for thumb triples (#102126)

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 ena

[ARM] Enable cfi-icall for thumb triples (#102126)

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.

show more ...

[PAC][Driver] Support `pauthtest` ABI for AArch64 Linux triples (#97237)

When `pauthtest` is either passed as environment part of AArch64 Linux
triple
or passed via `-mabi=`, enable the following

[PAC][Driver] Support `pauthtest` ABI for AArch64 Linux triples (#97237)

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>

show more ...

[Clang][Driver] Skip empty strings in getAArch64MultilibFlags (#97827)

In a multilib setting, if you compile with a command line such as `clang
--target=aarch64-none-elf -march=armv8.9-a+rcpc3`,
`

[Clang][Driver] Skip empty strings in getAArch64MultilibFlags (#97827)

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.

show more ...

[Driver] Support using toolchain libc and libc++ for baremetal (#96736)

We want to support using a complete Clang/LLVM toolchain that includes
LLVM libc and libc++ for baremetal targets. To do so,

[Driver] Support using toolchain libc and libc++ for baremetal (#96736)

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.

show more ...

Re-land: "[AArch64] Add ability to list extensions enabled for a target" (#95805) (#96795)

This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list

Re-land: "[AArch64] Add ability to list extensions enabled for a target" (#95805) (#96795)

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.

show more ...