Summary:
This patch cleans up how we query the offloading toolchain. We create a
single that is more similar to the existing `getToolChain` driver
function and make all the offloading handlers use it.
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).
Summary:
OpenMP was weirdly split between using the bound architecture from
`--offload-arch=` and the old `-march=` option which only worked for
single jobs. This patch removes that special handling. The main benefit
here is that we can now use `getToolchainArgs` without it throwing an
error.
I'm assuming SYCL doesn't care about this because they don't use an
architecture.
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.
The only architecture currently being supported (still a WIP) is
x86_64. Other UEFI triples targeting other architectures will now
report an `unknown target triple` error.
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`.
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'
```
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.
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.
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.
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.
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.
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.
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.
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
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>
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.
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`.
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.
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
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.
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
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
The -time option prints timing information for the subcommands
(compiler, linker) in a format similar to that used by gcc/gfortran.
This partially addresses requests from #89888
Executing `clang -Wp,` without any argument value causes Undefined
Behavior due to accessing a SmallVector without elements
Executing clang in debug mode raises an assert and Valgrind complains as
follow:
```
$ valgrind bin/clang -Wp,
==18620== Memcheck, a memory error detector
==18620== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==18620== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==18620== Command: bin/clang -Wp,
==18620==
==18620== Conditional jump or move depends on uninitialised value(s)
==18620== at 0x44F215B: clang::driver::Driver::TranslateInputArgs(llvm::opt::InputArgList const&) const (in /home/jaime/devel/llvm-project/build/bin/clang-20)
==18620== by 0x4515831: clang::driver::Driver::BuildCompilation(llvm::ArrayRef<char const*>) (in /home/jaime/devel/llvm-project/build/bin/clang-20)
==18620== by 0x10B3435: clang_main(int, char**, llvm::ToolContext const&) (in /home/jaime/devel/llvm-project/build/bin/clang-20)
==18620== by 0xF78F99: main (in /home/jaime/devel/llvm-project/build/bin/clang-20)
==18620==
...
```
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.
Follow-up on https://github.com/llvm/llvm-project/pull/109607, we have a
use case on Windows-on-ARM64 where `cmake -G "Unix Makefiles"` generates
`-fuse-ld=lld-link`, which is accidentally disallowed by PR#109607.
This PR is one of the many PRs in the SYCL upstreaming effort focusing
on device code linking during the SYCL offload compilation process. RFC:
https://discourse.llvm.org/t/rfc-offloading-design-for-sycl-offload-kind-and-spir-targets/74088
In this PR, we introduce a new tool that will be used to perform device
code linking for SYCL offload kind. It accepts SYCL device objects in
LLVM IR bitcode format and will generate a fully linked device object
that can then be wrapped and linked into the host object.
A primary use case for this tool is to perform device code linking for
objects with SYCL offload kind inside the clang-linker-wrapper. It can
also be invoked via clang driver as follows:
`clang --target=spirv64 --sycl-link input.bc`
Device code linking for SYCL offloading kind has a number of known
quirks that makes it difficult to use in a unified offloading setting.
Two of the primary issues are:
1. Several finalization steps are required to be run on the fully-linked
LLVM IR bitcode to gaurantee conformance to SYCL standards. This step is
unique to SYCL offloading compilation flow.
2. SPIR-V LLVM Translator tool is an extenal tool and hence SPIR-V IR
code generation cannot be done as part of LTO. This limitation will be
lifted once SPIR-V backend is available as a viable LLVM backend.
Hence, we introduce this new tool to provide a clean wrapper to perform
SYCL device linking.
Co-Author: Michael Toguchi
Thanks
---------
Signed-off-by: Arvind Sudarsanam <arvind.sudarsanam@intel.com>
Gentoo is planning to introduce a `*t64` suffix for triples that will be
used by 32-bit platforms that use 64-bit `time_t`. Add support for
parsing and accepting these triples, and while at it make clang
automatically enable the necessary glibc feature macros when this suffix
is used.
An open question is whether we can backport this to LLVM 19.x. After
all, adding new triplets to Triple sounds like an ABI change — though I
suppose we can minimize the risk of breaking something if we move new
enum values to the very end.
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>
Shipping a system configuration file for Clang is useful, but it limits
the relocatability of the toolchain because it bakes in a reference to
an absolute path on the file system.
Let's fix that by allowing for `CLANG_CONFIG_FILE_SYSTEM_DIR` to be set
to a relative path, and then interpreting that relative to the location
of the driver if applicable.
This would be useful for the LLVM package we ship at Homebrew. We
currently have to bake in a `DEFAULT_SYSROOT` in order to ship a
toolchain that works out of the box on macOS. If
`CLANG_CONFIG_FILE_SYSTEM_DIR` supported relative paths, we could
replace that with a configuration file which would be easier to update
when the compiled-in `DEFAULT_SYSROOT` becomes stale (e.g. on macOS
version upgrades).
We could, of course, set `CLANG_CONFIG_FILE_SYSTEM_DIR` to an absolute
path to begin with. However, we do have users who install Homebrew into
a prefix that is different from the one used on our buildbots, so doing
this would result in a broken toolchain for those users.
Similar to previous PRs I've done to change some `IsCLMode` checks to
`isWindowsMSVCEnvironment`.
I stumbled into this one accidentally last week. I did some greps and I
think this is the last one for now. All the remaining `IsCLMode` checks
are only valid for the cl driver mode.
For the `*-windows-msvc` target MSVC link.exe and lld are supported. LTO
isn't supported with MSVC link.exe and so we error when lto is enabled
but MSVC link.exe is being used. However we only error if the driver
mode is cl.
If we are using the clang driver with the `*-windows-msvc` target then
ensure an error is also emitted when LTO and MSVC link.exe are used
together.
An example of this is the -mpure-code option. Without a config file
being used, an error message will print `-mpure-code`. But if a config
file is used, the error message will print `-mexecute-only`.
This adds support for:
* `muslabin32` (MIPS N32)
* `muslabi64` (MIPS N64)
* `muslf32` (LoongArch ILP32F/LP64F)
* `muslsf` (LoongArch ILP32S/LP64S)
As we start adding glibc/musl cross-compilation support for these
targets in Zig, it would make our life easier if LLVM recognized these
triples. I'm hoping this'll be uncontroversial since the same has
already been done for `musleabi`, `musleabihf`, and `muslx32`.
I intentionally left out a musl equivalent of `gnuf64` (LoongArch
ILP32D/LP64D); my understanding is that Loongson ultimately settled on
simply `gnu` for this much more common case, so there doesn't *seem* to
be a particularly compelling reason to add a `muslf64` that's basically
deprecated on arrival.
Note: I don't have commit access.
Introduce changes necessary for UEFI X86_64 target Clang driver.
Addressed the review comments originally suggested in Phabricator.
Differential Revision: https://reviews.llvm.org/D159541
