Clang has support of virtual file system for the purpose of testing, but
treatment of config files did not use it. This change enables VFS in it
as well.
Differential Revision: https://reviews.llvm.org/D132867
Clang has support of virtual file system for the purpose of testing, but
treatment of config files did not use it. This change enables VFS in it
as well.
Differential Revision: https://reviews.llvm.org/D132867
Summary:
Previously the new driver crashed when using `-fsyntax-only` which
required a work-around in one of the test files. This was not properly
updated when it was fixed for the new driver. This patch fixes the test
and also adjusts a missing boolean check.
The new driver currently crashses when attempting to use the
'-fsyntax-only' option. This is because the option causes all output to
be given the `TY_Nothing' type which should signal the end of the
pipeline. The new driver was not treating this correctly and attempting
to use empty input. This patch fixes the handling so we do not attempt
to continue when the input is nothing.
One concession is that we must now check when generating the arguments
for Clang if the input is of 'TY_Nothing'. This is because the new
driver will only create code if the device code is a dependency on the
host, creating the output without the dependency would require a
complete rewrite of the logic as we do not maintain any state between
calls to 'BuildOffloadingActions' so I believe this is the most
straightforward method.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D133161
The changes in D130020 removed all support for the old method of
compiling OpenMP offloading programs. This means that
`-fopenmp-new-driver` has no effect and `-fno-openmp-new-driver` does
not work. This patch removes the use and documentation of this flag.
Note that the `--offload-new-driver` flag still exists for using the new
driver optionally with CUDA and HIP.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D133367
This implements setting the equivalent of `-fcrash-diagnostics-dir`
through the environment variable `CLANG_CRASH_DIAGNOSTICS_DIR`.
If present, the flag still takes precedence.
This helps integration with test frameworks and pipelines.
With this feature, we change the libcxx bootstrapping build
pipeline to produce clang crash reproducers as artifacts.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D133082
1. This implementation change the default storing behavior of -ftime-trace only.
That is, if the compiling job contains the linking action, the executable file' s directory may be seem as the main work directory.
Thus the time trace files would be stored in the same directory of linking result.
By this approach, the user can easily get the time-trace files in the main work directory. The improved demo results:
```
$ clang++ -ftime-trace -o main.out /demo/main.cpp
$ ls .
main.out main-[random-string].json
```
2. In addition, the main codes of time-trace files' path inference have been refactored.
* The <path> of -ftime-trace=<path> is infered in clang driver
* After that, -ftime-trace=<path> can be added into clang's options
By this approach, the dirty work of path processing and judging can be implemented in driver layer, so that the clang may focus on its main work.
# $ clang -ftime-trace -o xxx.out xxx.cpp
Differential Revision: https://reviews.llvm.org/D131469
* If GCC is configured with `--disable-multi-arch`, `--print-multiarch` output is an empty line.
* If GCC is configured with `--enable-multi-arch`, `--print-multiarch` output may be a normalized triple or (on Debian, 'vendor' is omitted) `x86_64-linux-gnu`.
The Clang support D101400 just prints the Debian multiarch style triple
unconditionally, but the string is not really expected for non-Debian systems.
AIUI many Linux distributions and non-Linux OSes don't configure GCC with `--enable-multi-arch`.
Instead of getting us in the trouble of supporting all kinds of variants, drop the support as before D101400.
Close https://github.com/llvm/llvm-project/issues/51469
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D133170
-fsyntax-only breaks down CUDA compilation pipeline and make it look like
multiple independent subcompilations and that trips the multiple arguments check
when -o is specified.
We do want to allow -fsyntax-only to be used with otherwise unmodified clang
options as it's commonly used by various tooling.
Differential Revision: https://reviews.llvm.org/D133133
Summary:
A previous patch removed the use of the `OK` private variable in CUDA
which resulted in usused variable warnings. this was fixed in
f886f7e8ef but did not change the
constructor to accurately represent its removal. This patch removes it
from the interface entirely.
Recently OpenMP has transitioned to using the "new" driver which
primarily merges the device and host linking phases into a single
wrapper that handles both at the same time. This replaced a few tools
that were only used for OpenMP offloading, such as the
`clang-offload-wrapper` and `clang-nvlink-wrapper`. The new driver
carries some marked benefits compared to the old driver that is now
being deprecated. Things like device-side LTO, static library
support, and more compatible tooling. As such, we should be able to
completely deprecate the old driver, at least for OpenMP. The old driver
support will still exist for CUDA and HIP, although both of these can
currently be compiled on Linux with `--offload-new-driver` to use the new
method.
Note that this does not deprecate the `clang-offload-bundler`, although
it is unused by OpenMP now, it is still used by the HIP toolchain both
as their device binary format and object format.
When I proposed deprecating this code I heard some vendors voice
concernes about needing to update their code in their fork. They should
be able to just revert this commit if it lands.
Reviewed By: jdoerfert, MaskRay, ye-luo
Differential Revision: https://reviews.llvm.org/D130020
The new driver supports device-only compilation for the offloading
device. The way this is handlded is a little different from the old
offloading driver. The old driver would put all the outputs in the final
action list akin to a linker job. The new driver however generated these
in the middle of the host's job so we instead put them all in a single
offloading action. However, we only handled these kinds of offloading
actions correctly when there was only a single input. When we had
multiple inputs we would instead attempt to get the host job, which
didn't exist, and crash.
This patch simply adds some extra logic to generate the jobs for all
dependencies if there is not host action.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D132248
Use this instead of `*_LIBDIR_SUFFIX`, from which it is computed.
This gets us ready for D130586, in which `*_LIBDIR_SUFFIX` is
deprecated.
Differential Revision: https://reviews.llvm.org/D132300
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
If directory for config files was specified in project configuration
using parameters CLANG_CONFIG_FILE_SYSTEM_DIR or CLANG_CONFIG_FILE_USER_DIR,
it was not overriden by command-line option `--config-system-dir=` or
`--config-user-dir=` that specified empty path.
This change corrects the behavior. It fixes the issue
https://github.com/llvm/llvm-project/issues/56836 ([clang] [test]
test/Driver/config-file-errs.c fails if CLANG_CONFIG_FILE_SYSTEM_DIR is
specified).
When not set output, set default output to stdout.
When set output with -Fo and no -fcgl, set -emit-obj to generate dx container.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D130858
The new driver primarily allows us to support RDC-mode compilations with
proper linking. This is not needed for non-RDC mode compilation, but we
still would like the new driver to be able to handle this mode so we can
transition away from the old driver in the future. This patch adds the
necessary code to support creating a fatbinary for HIP code generation.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D129784
A new option -I is added for dxc mode.
It is just alias of existing cc1 -I option.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D128462
The new driver generated offloadinga actions for each active toolchain.
However, for CUDA and HIP it is possible for the toolchain to be active
but one of the files is not a valid input. This can occur if the user
compiles both a CUDA and C source file in the same compiler invocation.
This patch adds some simple logic to quit if the input is not valid as
well.
Reviewed By: tra, MaskRay
Differential Revision: https://reviews.llvm.org/D129885
The new driver primarily allows us to support RDC-mode compilations with
proper linking. This is not needed for non-RDC mode compilation, but we
still would like the new driver to be able to handle this mode so we can
transition away from the old driver in the future. This patch adds the
necessary code to support creating a fatbinary for CUDA code generation
as well as removing old assumptions and errors about RDC-mode with the
new driver.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D129655
OpenMP supports multiple offloading toolchains and architectures. In
order to support this we originally used `getArgsForToolchain` to get
the arguments only intended for each toolchain. This allowed users to
manually specify if an `--offload-arch=` argument was intended for which
toolchain using `-Xopenmp-target=` or other methods. For example,
```
clang input.c -fopenmp -fopenmp-targets=nvptx64,amdgcn -Xopenmp-target=nvptx64 --offload-arch=sm_70 -Xopenmp-target=amdgcn --offload-arch=gfx908
```
However, this was causing problems with the AMDGPU toolchain. This is
because the AMDGPU toolchain for OpenMP uses an `amdgpu` arch to determine the
architecture. If this tool is not availible the compiler will exit with an error
even when manually specifying the architecture. This patch pulls out the logic in
`getArgsForToolchain` and specializes it for extracting `--offload-arch`
arguments to avoid this.
Reviewed By: JonChesterfield, yaxunl
Differential Revision: https://reviews.llvm.org/D129435
Also make the output of -emit-ast end up where /o points.
The same with .plist files from the static analyzer.
These are changes needed to make it possible to do CTU static
analysing work with clang-cl.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D128409
Previously, when using the new driver we created a fatbinary with the
PTX and Cubin output. This was mainly done in an attempt to create some
backwards compatibility with the existing CUDA support that embeds the
fatbinary in each TU. This will most likely be more work than necessary
to actually implement. The linker wrapper cannot do anything with these
embedded PTX files because we do not know how to link them, and if we
did want to include multiple files it should go through the
`clang-offload-packager` instead. Also this didn't repsect the setting
that disables embedding PTX (although it wasn't used anyway).
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D128441
This patch updates the `--[no-]offload-arch` command line arguments to
allow the user to pass in many architectures in a single argument rather
than specifying it multiple times. This means that the following command
line,
```
clang foo.cu --offload-arch=sm_70 --offload-arch=sm_80
```
can become:
```
clang foo.cu --offload-arch=sm_70,sm_80
```
Reviewed By: ye-luo
Differential Revision: https://reviews.llvm.org/D128206
Previously, each job would overwrite the -MJ file. This didn't quite work for Clang invocations with multiple architectures, which got fixed in D121997 by always appending to the -MJ file. That's not correct either, since the file would grow indefinitely on subsequent Clang invocations. This patch ensures the driver always removes the file before jobs fill it in by appending.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D128098
The offloading packager doesn't have a normal offloading kind. This
would result in its output being sent to the executable name when in
save-temps mode. This would then get overwritten by the actual output.
This patch adds specific checks to make sure that it gets the correct
name.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D127673
We use the flags `--offload-host-only` and `--offload-device-only` to
change the driver's code generation for offloading programs. These are
currently parsed out independently in many places. This patch simply
refactors this to work as a mode for the Driver. This stopped us from
emitting warnings if unused because it's always used now, but I don't
think this is a great loss.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D127515
This patch introduces the new -fdriver-only flag which instructs Clang to only execute the driver logic without running individual jobs. In a way, this is very similar to -###, with the following differences:
* it doesn't automatically print all jobs,
* it doesn't avoid side effects (e.g. it will generate compilation database when -MJ is specified).
This flag will be useful in testing D121997.
Reviewed By: dexonsmith, egorzhdan
Differential Revision: https://reviews.llvm.org/D127408
This is to avoid err_target_unknown_abi which is caused by use default TargetTriple instead of shader model target triple.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D125585
`-gen-reproducer` causes crash reproduction to be emitted
even when clang didn't crash, and now can optionally take an
argument of never, on-crash (default), on-error and always.
Differential revision: https://reviews.llvm.org/D120201
-gen-reproducer causes crash reproduction to be emitted even
when clang didn't crash, and now can optionally take an argument
of never, on-crash (default), on-error and always.
Differential revision: https://reviews.llvm.org/D120201
The new driver uses an augmented linker wrapper to perform the device
linking phase, but to the user looks like a regular linker invocation.
Contrary to the old driver, the new driver contains all the information
necessary to produce a linked device image in the host object itself.
Currently, we infer the usage of the device linker by the user
specifying an offloading toolchain, e.g. (--offload-arch=...) or
(-fopenmp-targets=...), but this shouldn't be strictly necessary.
This patch introduces a new option `--offload-link` to tell
the driver to use the offloading linker instead. So a compilation flow
can now look like this,
```
clang foo.cu --offload-new-driver -fgpu-rdc --offload-arch=sm_70 -c
clang foo.o --offload-link -lcudart
```
I was considering if this could be merged into the `-fuse-ld` option,
but because the device linker wraps over the users linker it would
conflict with that. In the future it's possible to merge this into `lld`
completely or `gold` via a plugin and we would use this option to
enable the device linking feature. Let me know what you think for this.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D126398
The Clang driver additional stages to build a complete offloading
program for applications using CUDA or OpenMP offloading. This normally
requires either a source file input or a valid object file to be
handled. This would cause problems when trying to compile an assembly or
LLVM IR file through clang with flags that would enable offloading. This
patch simply adds a check to prevent the offloading toolchain from being
used if we don't have a valid source file.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D125705
Serge Pavlov