Revert "[AMDGPU] Use the AMDGPUToolChain when targeting C/C++ directly (#99687)"

Breaks some downstream AMD stuff apparently.
This reverts commit 6ff86f2c0a5b58b07921ee895f0d16d8cd3d4015.

[AMDGPU] Use the AMDGPUToolChain when targeting C/C++ directly (#99687)

Summary:
The `getToolChain` pass uses the triple to determine which toolchain to
create. Currently the `amdgcn-amd-amdhsa` t

[AMDGPU] Use the AMDGPUToolChain when targeting C/C++ directly (#99687)

Summary:
The `getToolChain` pass uses the triple to determine which toolchain to
create. Currently the `amdgcn-amd-amdhsa` triple maps to the
`ROCmToolChain` which uses things expected to be provided by `ROCm`.
This is neded for OpenCL, but directly targeting C++ does not want this
since it's primarily being used for creating GPU runtime code. As far as
I know I'm the only user of this, so this shouldn't change anything.

Unfortunately, there's no good logic for detercting this, so I simply
checked ahead of time if the input is either `foo.cl` or `-x cl foo.c`
to choose between the two. This allows us to use the AMDGPU target
normally, as otherwise it will error without passing `-nogpulib`.

show more ...

[Multilib] Custom flags processing for library selection (#110659)

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

[Multilib] Custom flags processing for library selection (#110659)

This patch is the third 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. This particular patch is comprised
of the core processing of these flags.

- Custom flags in the command-line are read and forwarded to the
multilib system. If multiple flag values are present for the same flag
declaration, the last one wins. Default flag values are inserted for
flag declarations for which no value was given.
- Feed `MacroDefines` back into the driver. Each item `<string>` in the
`MacroDefines` list is formatted as `-D<string>`.

Library variants should list their requirement on one or more custom
flags like they do for any other flag. The new command-line option is
passed as-is to the multilib system, therefore it should be listed in
the format `-fmultilib-flag=<str>`.

Moreover, a variant that does not specify a requirement on any
particular flag can be matched against any value of that flag.

If the user specifies `-fmultilib-flag=<name>` with a name that is
invalid, but close enough to any valid flag value name in terms of edit
distance, a suggesting error is shown:
```
error: unsupported option '-fmultilib-flag=invalidname'; did you mean '-fmultilib-flag=validname'?
```
The candidate with the smallest edit distance is chosen for the
suggestion, up to a certain maximum value (implementation detail), after
which a non-suggesting error is shown instead:
```
error: unsupported option '-fmultilib-flag=invalidname'
```

show more ...

[CUDA][HIP] Support CUID in new driver (#122859)

CUID is needed by CUDA/HIP for supporting accessing static device
variables in host function.

Currently CUID is only supported by the old driver

[CUDA][HIP] Support CUID in new driver (#122859)

CUID is needed by CUDA/HIP for supporting accessing static device
variables in host function.

Currently CUID is only supported by the old driver for CUDA/HIP. The new
driver does not support it, which causes CUDA/HIP programs using static
device variables in host functions to fail with the new driver for
CUDA/HIP.

This patch refactors the CUID support in the old driver so that CUID is
supported by both the old and the new drivers for CUDA/HIP.

show more ...

[C++20] [Modules] [Driver] Support -print-library-module-manifest-path for libstdc++

Given libstdc++ has landed std module, the build systems may need clang
to find the configuration file to underst

[C++20] [Modules] [Driver] Support -print-library-module-manifest-path for libstdc++

Given libstdc++ has landed std module, the build systems may need clang
to find the configuration file to understand how to build the std
module. This patch did this. Tested with locally installed GCC-trunk.

show more ...

Fix print module manifest file for macos (#122370)

This commit fixes -print-library-module-manifest-path on macos.
Currently, this only works on linux systems. This is because on macos
systems the

Fix print module manifest file for macos (#122370)

This commit fixes -print-library-module-manifest-path on macos.
Currently, this only works on linux systems. This is because on macos
systems the library and header files are installed in a different
location. The module manifest is next to the libraries and the search
function was not looking in both places. There is also a test included.

show more ...

[Driver] Avoid repeated map lookups (NFC) (#122625)

[CUDA] Move CUDA to new driver by default (#122312)

Summary:
This patch updates the --offload-new-driver flag to be default for CUDA.
This mostly just required updating a lot of tests to use the old

[CUDA] Move CUDA to new driver by default (#122312)

Summary:
This patch updates the --offload-new-driver flag to be default for CUDA.
This mostly just required updating a lot of tests to use the old format.
I tried to update them where possible, but some were directly checking
the old format.


https://discourse.llvm.org/t/rfc-use-the-new-offloding-driver-for-cuda-and-hip-compilation-by-default/77468/18

show more ...

[HLSL] Explicitly set the SPIR-V version with spv-target-env (#121961)

In DXC, setting the vulkan version automatically sets the target spir-v
version to the maximum spir-v version that the vulkan v

[HLSL] Explicitly set the SPIR-V version with spv-target-env (#121961)

In DXC, setting the vulkan version automatically sets the target spir-v
version to the maximum spir-v version that the vulkan version must
support. So for Vulkan 1.2, we set the spir-v version to spirv 1.5
because every implementation of Vulkan 1.2 must support spirv 1.5, but
not spir-v 1.6.

show more ...

[Darwin][Driver][clang] apple-none-macho orders the resource directory after internal-externc-isystem when nostdlibinc is used (#122035)

Embedded development often needs to use a different C standar

[Darwin][Driver][clang] apple-none-macho orders the resource directory after internal-externc-isystem when nostdlibinc is used (#122035)

Embedded development often needs to use a different C standard library,
replacing the existing one normally passed as -internal-externc-isystem.
This works fine for an apple-macos target, but apple-none-macho doesn't
work because the MachO driver doesn't implement
AddClangSystemIncludeArgs to add the resource directory as
-internal-isystem like most other drivers do. Move most of the search
path logic from Darwin and DarwinClang down into an AppleMachO toolchain
between the MachO and Darwin toolchains.

Also define __MACH__ for apple-none-macho, as Swift expects all MachO
targets to have that defined.

show more ...

[SystemZ][z/OS] Add z/OS customization file (#111182)

On z/OS, the location of the system libraries and side decks (aka
equivalent to libc, etc) are not in a predefined location. The system
does h

[SystemZ][z/OS] Add z/OS customization file (#111182)

On z/OS, the location of the system libraries and side decks (aka
equivalent to libc, etc) are not in a predefined location. The system
does have a default location but sysadmins can change this and
frequently do. See the -mzos-hlq* options we have for z/OS.

To avoid every user needing to specify these -mzos-hlq* options, we
added support for a system install default config file that is always
read independent of the usual config file. The compiler will read this
customization config file before reading the usual config files.

The customization file is called clang.cfg and is located in:
- the etc dir within the compiler installation dir.
- or specified by the CLANG_CONFIG_PATH env var. This env var can either
be a directory or the fill path name of the file.

show more ...

Revert "[Darwin][Driver][clang] apple-none-macho orders the resource directory after internal-externc-isystem when nostdlibinc is used (#120507)"

This reverts commit 653a54727eaa18c43447ad686c987db6

Revert "[Darwin][Driver][clang] apple-none-macho orders the resource directory after internal-externc-isystem when nostdlibinc is used (#120507)"

This reverts commit 653a54727eaa18c43447ad686c987db67f1dda74.
Breaks tests, see https://github.com/llvm/llvm-project/pull/120507#issuecomment-2575246281

show more ...

[Darwin][Driver][clang] apple-none-macho orders the resource directory after internal-externc-isystem when nostdlibinc is used (#120507)

Embedded development often needs to use a different C standar

[Darwin][Driver][clang] apple-none-macho orders the resource directory after internal-externc-isystem when nostdlibinc is used (#120507)

Embedded development often needs to use a different C standard library,
replacing the existing one normally passed as -internal-externc-isystem.
This works fine for an apple-macos target, but apple-none-macho doesn't
work because the MachO driver doesn't implement
AddClangSystemIncludeArgs to add the resource directory as
-internal-isystem like most other drivers do. Move most of the search
path logic from Darwin and DarwinClang down into an AppleMachO toolchain
between the MachO and Darwin toolchains.

Also define \_\_MACH__ for apple-none-macho, as Swift expects all MachO
targets to have that defined.

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][clang-linker-wrapper] Add initial support for OpenMP offloading to generic SPIR-V (#120145)

This is the first of a series of patches to add support for OpenMP
offloading to SPIR-V through

[Driver][clang-linker-wrapper] Add initial support for OpenMP offloading to generic SPIR-V (#120145)

This is the first of a series of patches to add support for OpenMP
offloading to SPIR-V through liboffload with the first intended target
being Intel GPUs. This patch implements the basic driver and
`clang-linker-wrapper` work for JIT mode. There are still many missing
pieces, so this is not yet usable.

We introduce `spirv64-intel-unknown` as the only currently supported
triple. The user-facing argument to enable offloading will be `-fopenmp
-fopenmp-targets=spirv64-intel`

Add a new `SPIRVOpenMPToolChain` toolchain based on the existing general
SPIR-V toolchain which will call all the required SPIR-V tools (and
eventually the SPIR-V backend) as well as add the corresponding device
RTL as an argument to the linker.

We can't get through the front end consistently yet, so it's difficult
to add any LIT tests that execute any tools, but front end changes are
planned very shortly, and then we can add those tests.

---------

Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>

show more ...

[clang][Driver] Support simplified triple versions for config files (#111387)

Currently, the config file system loads the full target triple, e.g.
`arm64-apple-darwin23.6.0.cfg`.

This is however

[clang][Driver] Support simplified triple versions for config files (#111387)

Currently, the config file system loads the full target triple, e.g.
`arm64-apple-darwin23.6.0.cfg`.

This is however not very useful as this is a moving target. In the case
of macOS, that target moves every ~2 months.

We can improve this by adding fallbacks that simplify the version
component of the triple. This pull request adds support for loading
`arm64-apple-darwin23.cfg` and `arm64-apple-darwin.cfg`. See the
included test for a demonstration on how it works.

show more ...

Eliminate duplicate call in Clang driver (NFC)

The only difference is the usage of `JobAction* JA` versus `Action* A`
in one argument, but `JA = cast<JobAction>(A)`, and the called function
is inher

Eliminate duplicate call in Clang driver (NFC)

The only difference is the usage of `JobAction* JA` versus `Action* A`
in one argument, but `JA = cast<JobAction>(A)`, and the called function
is inherited from `Action`.

show more ...

[clang][driver] Use $ prefix with config file options to have them added after all of the command line options (#117573)

Currently, if a -l (or -Wl,) flag is added into a config file
(e.g. clang.cf

[clang][driver] Use $ prefix with config file options to have them added after all of the command line options (#117573)

Currently, if a -l (or -Wl,) flag is added into a config file
(e.g. clang.cfg), it is situated before any object file in the
effective command line. If the library requested by given -l flag is
static, its symbols will not be made visible to any of the object
files provided by the user. Also, the presence of any of the linker
flags in a config file confuses the driver whenever the user invokes
clang without any parameters (see issue #67209).

This patch attempts to solve both of the problems, by allowing a split
of the arguments list into two parts. The head part of the list will
be used as before, but the tail part will be appended after the
command line flags provided by the user and only when it is known
that the linking should occur. The $-prefixed arguments will be added
to the tail part.

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] BuildCompilation: remove unused BaseArg. NFC

setBaseArg, only used by -XArch_* options, are called in BuildJobs.
When processing --config and CL /clang:, BaseArg is always nullptr.

The unn

[Driver] BuildCompilation: remove unused BaseArg. NFC

setBaseArg, only used by -XArch_* options, are called in BuildJobs.
When processing --config and CL /clang:, BaseArg is always nullptr.

The unneeded parameter was introduced in https://reviews.llvm.org/D24933

show more ...

[Clang][Driver] report unsupported option error when link + compile in same process (#116476)

Fixes: https://github.com/llvm/llvm-project/issues/116278

This change updates clang to report unsuppo

[Clang][Driver] report unsupported option error when link + compile in same process (#116476)

Fixes: https://github.com/llvm/llvm-project/issues/116278

This change updates clang to report unsupported option errors regardless
of the command line argument order.

When clang is invoked with a source file and without `-c` it will both
compile and link. When an unsupported option is also part of the command
line clang should generated an error. However, if the source file name
comes before an object file, eg: `-lc`, the error is ignored.

```
$ clang --target=x86_64 -lc hello.c -mhtm
clang: error: unsupported option '-mhtm' for target 'x86_64'
$ echo $?
1
```

but if `-lc` comes after `hello.c` the error is dropped

```
$ clang --target=x86_64 hello.c -mhtm -lc
$ echo $?
0
```

after this change clang will report the error regardless of the command
line argument order.

show more ...

[flang][Driver] Support -print-supported-cpus and associated aliases (#117199)

The aliases are -mcpu=help and -mtune=help. There is still an issue with
the output which prints an example line that

[flang][Driver] Support -print-supported-cpus and associated aliases (#117199)

The aliases are -mcpu=help and -mtune=help. There is still an issue with
the output which prints an example line that references clang. That is
not fixed here because it is printed in llvm/MC/SubtargetInfo.cpp. Some
more thought is needed to determine how best to handle this.

Fixes #117010

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