[HIP] Allow the new driver to compile HIP in non-RDC mode

The new driver primarily allows us to support RDC-mode compilations with
proper linking. This is not needed for non-RDC mode compilation, bu

[HIP] Allow the new driver to compile HIP in non-RDC mode

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

show more ...

[HLSL] add -I option for dxc mode.

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

[CUDA] Make the new driver properly ignore non-CUDA inputs

The new driver generated offloadinga actions for each active toolchain.
However, for CUDA and HIP it is possible for the toolchain to be ac

[CUDA] Make the new driver properly ignore non-CUDA inputs

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

show more ...

[clang] Use value instead of getValue (NFC)

[CUDA] Allow the new driver to compile CUDA in non-RDC mode

The new driver primarily allows us to support RDC-mode compilations with
proper linking. This is not needed for non-RDC mode compilation,

[CUDA] Allow the new driver to compile CUDA in non-RDC mode

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

show more ...

[Clang] Parse toolchain-specific offloading arguments directly

OpenMP supports multiple offloading toolchains and architectures. In
order to support this we originally used `getArgsForToolchain` to

[Clang] Parse toolchain-specific offloading arguments directly

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

show more ...

[clang-cl] Add -emit-ast to clang-cl driver

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 possib

[clang-cl] Add -emit-ast to clang-cl driver

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

show more ...

[clang] Don't use Optional::hasValue (NFC)

This patch replaces x.hasValue() with x where x is contextually
convertible to bool.

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[CUDA] Do not embed a fatbinary when using the new driver

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 som

[CUDA] Do not embed a fatbinary when using the new driver

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

show more ...

[Clang] Allow multiple comma separated arguments to `--offload-arch=`

This patch updates the `--[no-]offload-arch` command line arguments to
allow the user to pass in many architectures in a single

[Clang] Allow multiple comma separated arguments to `--offload-arch=`

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

show more ...

[clang] Don't use Optional::getValue (NFC)

Don't use Optional::hasValue (NFC)

[clang][driver] Ensure we don't accumulate entries in -MJ files

Previously, each job would overwrite the -MJ file. This didn't quite work for Clang invocations with multiple architectures, which got

[clang][driver] Ensure we don't accumulate entries in -MJ files

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

show more ...

[OpenMP] Fix offload packager not writing to temps correctly

The offloading packager doesn't have a normal offloading kind. This
would result in its output being sent to the executable name when in

[OpenMP] Fix offload packager not writing to temps correctly

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

show more ...

[Clang] Change host/device only compilation to a driver mode

We use the flags `--offload-host-only` and `--offload-device-only` to
change the driver's code generation for offloading programs. These

[Clang] Change host/device only compilation to a driver mode

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

show more ...

[clang][driver] Introduce new -fdriver-only flag

This patch introduces the new -fdriver-only flag which instructs Clang to only execute the driver logic without running individual jobs. In a way, th

[clang][driver] Introduce new -fdriver-only flag

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

show more ...

[clang][driver] adds `-print-diagnostics`

Prints a list of all the warnings that Clang offers.

Differential Revision: https://reviews.llvm.org/D126796

Use static_cast from SmallString to std::string (NFC)

[HLSL][clang][Driver] Parse target profile early to update Driver::TargetTriple.

This is to avoid err_target_unknown_abi which is caused by use default TargetTriple instead of shader model target tr

[HLSL][clang][Driver] Parse target profile early to update Driver::TargetTriple.

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

show more ...

[Clang] Extend -gen-reproducer flag

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

[Clang] Extend -gen-reproducer flag

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

show more ...

Revert "[Clang] Extend -gen-reproducer flag"

This reverts commit 684c080108766b4f112f172fed4a49059484614d.

[Clang] Extend -gen-reproducer flag

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

[Clang] Extend -gen-reproducer flag

-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

show more ...

[Clang] Introduce `--offload-link` option to perform offload device linking

The new driver uses an augmented linker wrapper to perform the device
linking phase, but to the user looks like a regular

[Clang] Introduce `--offload-link` option to perform offload device linking

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

show more ...