Class ExpansionContext encapsulates options for search and expansion of
response files, including configuration files. With this change the
directories which are searched for configuration files are also stored
in ExpansionContext.
Differential Revision: https://reviews.llvm.org/D135439
If an invalid architecture is set we currently return an empty string.
This will cause the offloading toolchain to continue to be built and
hit an assertion elsewhere due to the invalid architecture. This patch
fixes that so we now correctly exit.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D135791
The Offloading toolchain currently has two methods for construction the
requires actions. The "new" driver and the old `OffloadActionBuilder`.
Using either one is mutually exclusive, so we should not initialize this
when using the new driver. This was causing some error messages to be
printed multiple times because we were checking them in both the old and
the new driver.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D135715
The offloading toolchain makes heavy use of options beginning with
`--o`. This is problematic when combined with the joined `-o` flag. In
the following situation, the user will not get the expected output and
will not notice as the expected output will still be written.
```
clang++ -x cuda foo.cu -offload-arch=sm_80 -o foo
```
This patch introduces a warning that checks for joined `-o` arguments
that would also be a valid driver argument if an additional `-` were
added. I believe this situation is uncommon enough to warrant a warning,
and can be trivially fixed by the end user by using the more common
separate form instead.
Reviewed By: tra, MaskRay
Differential Revision: https://reviews.llvm.org/D135389
The new driver supports LTO for RDC-mode compilations. However, this was
not correctly handled for non-LTO compilations. HIP can handle this as
it is fed to `lld` which will perform the LTO itself. CUDA however would
require every work which is wholly useless in non-RDC mode so it should
report an error.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D135305
Add support for a CLANG_NO_DEFAULT_CONFIG envvar that works like
the --no-default-config option when set to a non-empty value. Use it
to disable loading system configuration files during the test suite
runs.
Configuration files can change the driver behavior in extensive ways,
and it is neither really possible nor feasible to account for or undo
the effects of even the most common configuration uses. Therefore,
the most reasonable option seems to be to ignore configuration files
while running the majority of tests (with the notable exception of tests
for configuration file support).
Due to the diversity of ways that %clang is used in the test suite,
including using it to copy or symlink the clang executable, as well to
call -cc1 and -cc1as modes, it is not feasible to pass the explicit
options to disable config loading either. Using an environment variable
has the advantage of being easily applied across the test suite
and easily unset for default configuration file loading tests.
Differential Revision: https://reviews.llvm.org/D134905
Change the default config file loading logic to be more flexible
and more readable at the same time. The new algorithm focuses on four
locations, in order:
1. <triple>-<mode>.cfg using real driver mode
2. <triple>-<mode>.cfg using executable suffix
3. <triple>.cfg + <mode>.cfg using real driver mode
4. <triple>.cfg + <mode>.cfg using executable suffix
This is meant to preserve reasonable level of compatibility with
the existing use, while introducing more flexibility and making the code
simpler. Notably:
1. In this layout, the actual target triple is normally respected,
and e.g. in `-m32` build the `x86_64-*` configs will never be used.
2. Both real driver mode (preferable) and executable suffix are
supported. This permits correctly handling calls with explicit
`--driver-mode=` while at the same time preserving compatibility
with the existing code.
3. The first two locations provide users with the ability to override
configuration per specific target+mode combinaton, while the next two
make it possible to independently specify per-target and per-mode
configuration.
4. All config file locations are applicable independently of whether
clang is started via a prefixed executable, or bare `clang`.
5. If the target is not explicitly specified and the executable prefix
does not name a valid triple, it is used instead of the actual target
triple for backwards compatibility.
This is particularly meant to address Gentoo's use case for
configuration files: to configure the default runtimes (i.e. `-rtlib=`,
`-stdlib=`) and `--gcc-install-dir=` for all the relevant drivers,
as well as to make it more convenient for users to override `-W` flags
to test compatibility with future versions of Clang easier.
Differential Revision: https://reviews.llvm.org/D134337
Functions that implement expansion of response and config files depend
on many options, which are passes as arguments. Extending the expansion
requires new options, it in turn causes changing calls in various places
making them even more bulky.
This change introduces a class ExpansionContext, which represents set of
options that control the expansion. Its methods implements expansion of
responce files including config files. It makes extending the expansion
easier.
No functional changes.
Differential Revision: https://reviews.llvm.org/D132379
Functions that implement expansion of response and config files depend
on many options, which are passes as arguments. Extending the expansion
requires new options, it in turn causes changing calls in various places
making them even more bulky.
This change introduces a class ExpansionContext, which represents set of
options that control the expansion. Its methods implements expansion of
responce files including config files. It makes extending the expansion
easier.
No functional changes.
Differential Revision: https://reviews.llvm.org/D132379
HIP is able to unbundle archive of bundled bitcode.
However currently there are two bugs:
1. archives passed by -l: are not unbundled.
2. archives passed as input files are not unbundled
The actual file name of an archive passed by -l: should
not be prefixed with lib and appended with '.a',
but the file path is prefixed with paths in '-L' options.
The actual file name of an archive passed as an input file
stays the same, not affected by the '-L' options.
This patch adds an additional check for if an options passed to the
Clang driver could've been intended for the clang compiler. This is
primarily done for the times when a user attempts to pass an option like
`-ast-dump` to the driver instead.
Reviewed By: MaskRay, aaron.ballman
Differential Revision: https://reviews.llvm.org/D134550
Support specifying multiple configuration files via multiple `--config`
options. When multiple files are specified, the options from subsequent
files are appended to the options from the initial file.
While at it, remove the incorrect assertion about CfgFileName being
non-empty. It can be empty if `--config ""` is passed, and it makes
sense to report it as non-existing file rather than crash.
Differential Revision: https://reviews.llvm.org/D134270
Disable transformations (e.g. attempting to replace target architecture)
in the config filename that is passed explicitly via `--config`. This
behavior is surprising and confusing -- if user passes an explicit
config filename, Clang should use it as is. The transformations are
still applied when the name is deduced from filename.
Update the tests accordingly. This primarily ensures that full filename
with .cfg suffix is passed to --config (appending `.cfg` implicitly is
not documented, and would collide with use of filenames with other
suffixes). The config-file2.c suite is removed entirely as it tested
the transformations on the argument to --config. However, the aspects
of that that were not tested as part of config-file3.c are now added
there (based on config filename deduced from executable).
This change streamlines the code in Driver::loadConfigFile(), opening
the possibility of further changes, including support for handling
multiple --config options and refactoring of filename deduction.
Differential Revision: https://reviews.llvm.org/D134208
Previously when using the `clang-offload-packager` we did not pass the
active offloading kinds. Then in Clang when we attempted to detect when
there was host-offloading action that needed to be embedded in the host
we did not find it. This patch adds the active offloading kinds so we
know when there is input to be embedded.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D134189
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
f886f7e8ef7aa4f54298db792a656373af90440c 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
