maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Driver/cuda-detect.cu

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

192 lines
10 KiB
Plaintext
Raw Normal View History

[CUDA] Added CUDA installation detector class. Added new option --cuda-path=<path> which allows overriding default search paths. If it's not specified we look for CUDA installation in /usr/include/cuda and /usr/include/cuda-7.0. Differential Revision: http://reviews.llvm.org/D12989 llvm-svn: 248433
2015-09-24 05:49:39 +08:00
// REQUIRES: clang-driver
// REQUIRES: x86-registered-target
[CUDA] added include paths for both sides of CUDA compilation. In order to compile a CUDA file clang must be able to find include files for both both host and device. This patch passes AuxToolchain to AddPreprocessingOptions and uses it to add include paths for the opposite side of compilation. We also must be able to find CUDA include files. If the driver found CUDA installation, it adds appropriate include path to CUDA headers. This can be disabled with '-nocudainc'. - Added include paths for the opposite side of compilation. - Added include paths to detected CUDA installation. - Added -nocudainc to prevent adding CUDA include path. - Added test cases to verify new functionality. Differential Revision: http://reviews.llvm.org/D13170 llvm-svn: 253386
2015-11-18 06:28:46 +08:00
// REQUIRES: nvptx-registered-target
[CUDA] Added CUDA installation detector class. Added new option --cuda-path=<path> which allows overriding default search paths. If it's not specified we look for CUDA installation in /usr/include/cuda and /usr/include/cuda-7.0. Differential Revision: http://reviews.llvm.org/D12989 llvm-svn: 248433
2015-09-24 05:49:39 +08:00
//
[CUDA] Require libdevice only if needed If the user passes -nocudalib, we can live without it being present. Simplify the code by just checking whether LibDeviceMap is empty. Differential Revision: https://reviews.llvm.org/D38901 llvm-svn: 315902
2017-10-16 21:31:30 +08:00
// Check that we properly detect CUDA installation.
[CUDA] Added CUDA installation detector class. Added new option --cuda-path=<path> which allows overriding default search paths. If it's not specified we look for CUDA installation in /usr/include/cuda and /usr/include/cuda-7.0. Differential Revision: http://reviews.llvm.org/D12989 llvm-svn: 248433
2015-09-24 05:49:39 +08:00
// RUN: %clang -v --target=i386-unknown-linux \
[CUDA] Detect installation in PATH If the CUDA toolkit is not installed to its default locations in /usr/local/cuda, the user is forced to specify --cuda-path. This is tedious and the driver can be smarter if well-known tools (like ptxas) can already be found in the PATH environment variable. Add option --cuda-path-ignore-env if the user wants to ignore set environment variables. Also use it in the tests to make sure the driver always finds the same CUDA installation, regardless of the user's environment. Differential Revision: https://reviews.llvm.org/D42642 llvm-svn: 323848
2018-01-31 16:26:51 +08:00
// RUN: --sysroot=%S/no-cuda-there --cuda-path-ignore-env 2>&1 | FileCheck %s -check-prefix NOCUDA
[CUDA] Driver changes to support CUDA compilation on MacOS. Summary: Compiling CUDA device code requires us to know the host toolchain, because CUDA device-side compiles pull in e.g. host headers. When we only supported Linux compilation, this worked because CudaToolChain, which is responsible for device-side CUDA compilation, inherited from the Linux toolchain. But in order to support MacOS, CudaToolChain needs to take a HostToolChain pointer. Because a CUDA toolchain now requires a host TC, we no longer will create a CUDA toolchain from Driver::getToolChain -- you have to go through CreateOffloadingDeviceToolChains. I am *pretty* sure this is correct, and that previously any attempt to create a CUDA toolchain through getToolChain() would eventually have resulted in us throwing "error: unsupported use of NVPTX for host compilation". In any case hacking getToolChain to create a CUDA+host toolchain would be wrong, because a Driver can be reused for multiple compilations, potentially with different host TCs, and getToolChain will cache the result, causing us to potentially use a stale host TC. So that's the main change in this patch. In addition, we have to pull CudaInstallationDetector out of Generic_GCC and into a top-level class. It's now used by the Generic_GCC and MachO toolchains. Reviewers: tra Subscribers: rryan, hfinkel, sfantao Differential Revision: https://reviews.llvm.org/D26774 llvm-svn: 287285
2016-11-18 08:41:22 +08:00
// RUN: %clang -v --target=i386-apple-macosx \
[CUDA] Detect installation in PATH If the CUDA toolkit is not installed to its default locations in /usr/local/cuda, the user is forced to specify --cuda-path. This is tedious and the driver can be smarter if well-known tools (like ptxas) can already be found in the PATH environment variable. Add option --cuda-path-ignore-env if the user wants to ignore set environment variables. Also use it in the tests to make sure the driver always finds the same CUDA installation, regardless of the user's environment. Differential Revision: https://reviews.llvm.org/D42642 llvm-svn: 323848
2018-01-31 16:26:51 +08:00
// RUN: --sysroot=%S/no-cuda-there --cuda-path-ignore-env 2>&1 | FileCheck %s -check-prefix NOCUDA
// RUN: %clang -v --target=x86_64-unknown-linux \
// RUN: --sysroot=%S/no-cuda-there --cuda-path-ignore-env 2>&1 | FileCheck %s -check-prefix NOCUDA
// RUN: %clang -v --target=x86_64-apple-macosx \
// RUN: --sysroot=%S/no-cuda-there --cuda-path-ignore-env 2>&1 | FileCheck %s -check-prefix NOCUDA
[CUDA] Driver changes to support CUDA compilation on MacOS. Summary: Compiling CUDA device code requires us to know the host toolchain, because CUDA device-side compiles pull in e.g. host headers. When we only supported Linux compilation, this worked because CudaToolChain, which is responsible for device-side CUDA compilation, inherited from the Linux toolchain. But in order to support MacOS, CudaToolChain needs to take a HostToolChain pointer. Because a CUDA toolchain now requires a host TC, we no longer will create a CUDA toolchain from Driver::getToolChain -- you have to go through CreateOffloadingDeviceToolChains. I am *pretty* sure this is correct, and that previously any attempt to create a CUDA toolchain through getToolChain() would eventually have resulted in us throwing "error: unsupported use of NVPTX for host compilation". In any case hacking getToolChain to create a CUDA+host toolchain would be wrong, because a Driver can be reused for multiple compilations, potentially with different host TCs, and getToolChain will cache the result, causing us to potentially use a stale host TC. So that's the main change in this patch. In addition, we have to pull CudaInstallationDetector out of Generic_GCC and into a top-level class. It's now used by the Generic_GCC and MachO toolchains. Reviewers: tra Subscribers: rryan, hfinkel, sfantao Differential Revision: https://reviews.llvm.org/D26774 llvm-svn: 287285
2016-11-18 08:41:22 +08:00
[CUDA] added include paths for both sides of CUDA compilation. In order to compile a CUDA file clang must be able to find include files for both both host and device. This patch passes AuxToolchain to AddPreprocessingOptions and uses it to add include paths for the opposite side of compilation. We also must be able to find CUDA include files. If the driver found CUDA installation, it adds appropriate include path to CUDA headers. This can be disabled with '-nocudainc'. - Added include paths for the opposite side of compilation. - Added include paths to detected CUDA installation. - Added -nocudainc to prevent adding CUDA include path. - Added test cases to verify new functionality. Differential Revision: http://reviews.llvm.org/D13170 llvm-svn: 253386
2015-11-18 06:28:46 +08:00
// RUN: %clang -v --target=i386-unknown-linux \
[CUDA] Fix two failed test cases using --cuda-path-ignore-env Add --cuda-path-ignore-env option to those test cases to ensure the clang driver always pick the CUDA path specified by --sysroot. Reviewers: tra, Hahnfeld Differential Revision: https://reviews.llvm.org/D52259 llvm-svn: 343075
2018-09-26 15:07:48 +08:00
// RUN: --sysroot=%S/Inputs/CUDA --cuda-path-ignore-env 2>&1 | FileCheck %s
[CUDA] Driver changes to support CUDA compilation on MacOS. Summary: Compiling CUDA device code requires us to know the host toolchain, because CUDA device-side compiles pull in e.g. host headers. When we only supported Linux compilation, this worked because CudaToolChain, which is responsible for device-side CUDA compilation, inherited from the Linux toolchain. But in order to support MacOS, CudaToolChain needs to take a HostToolChain pointer. Because a CUDA toolchain now requires a host TC, we no longer will create a CUDA toolchain from Driver::getToolChain -- you have to go through CreateOffloadingDeviceToolChains. I am *pretty* sure this is correct, and that previously any attempt to create a CUDA toolchain through getToolChain() would eventually have resulted in us throwing "error: unsupported use of NVPTX for host compilation". In any case hacking getToolChain to create a CUDA+host toolchain would be wrong, because a Driver can be reused for multiple compilations, potentially with different host TCs, and getToolChain will cache the result, causing us to potentially use a stale host TC. So that's the main change in this patch. In addition, we have to pull CudaInstallationDetector out of Generic_GCC and into a top-level class. It's now used by the Generic_GCC and MachO toolchains. Reviewers: tra Subscribers: rryan, hfinkel, sfantao Differential Revision: https://reviews.llvm.org/D26774 llvm-svn: 287285
2016-11-18 08:41:22 +08:00
// RUN: %clang -v --target=i386-apple-macosx \
[CUDA] Fix two failed test cases using --cuda-path-ignore-env Add --cuda-path-ignore-env option to those test cases to ensure the clang driver always pick the CUDA path specified by --sysroot. Reviewers: tra, Hahnfeld Differential Revision: https://reviews.llvm.org/D52259 llvm-svn: 343075
2018-09-26 15:07:48 +08:00
// RUN: --sysroot=%S/Inputs/CUDA --cuda-path-ignore-env 2>&1 | FileCheck %s
[CUDA] Driver changes to support CUDA compilation on MacOS. Summary: Compiling CUDA device code requires us to know the host toolchain, because CUDA device-side compiles pull in e.g. host headers. When we only supported Linux compilation, this worked because CudaToolChain, which is responsible for device-side CUDA compilation, inherited from the Linux toolchain. But in order to support MacOS, CudaToolChain needs to take a HostToolChain pointer. Because a CUDA toolchain now requires a host TC, we no longer will create a CUDA toolchain from Driver::getToolChain -- you have to go through CreateOffloadingDeviceToolChains. I am *pretty* sure this is correct, and that previously any attempt to create a CUDA toolchain through getToolChain() would eventually have resulted in us throwing "error: unsupported use of NVPTX for host compilation". In any case hacking getToolChain to create a CUDA+host toolchain would be wrong, because a Driver can be reused for multiple compilations, potentially with different host TCs, and getToolChain will cache the result, causing us to potentially use a stale host TC. So that's the main change in this patch. In addition, we have to pull CudaInstallationDetector out of Generic_GCC and into a top-level class. It's now used by the Generic_GCC and MachO toolchains. Reviewers: tra Subscribers: rryan, hfinkel, sfantao Differential Revision: https://reviews.llvm.org/D26774 llvm-svn: 287285
2016-11-18 08:41:22 +08:00
[CUDA] Added CUDA installation detector class. Added new option --cuda-path=<path> which allows overriding default search paths. If it's not specified we look for CUDA installation in /usr/include/cuda and /usr/include/cuda-7.0. Differential Revision: http://reviews.llvm.org/D12989 llvm-svn: 248433
2015-09-24 05:49:39 +08:00
// RUN: %clang -v --target=i386-unknown-linux \
// RUN: --cuda-path=%S/Inputs/CUDA/usr/local/cuda 2>&1 | FileCheck %s
[CUDA] Driver changes to support CUDA compilation on MacOS. Summary: Compiling CUDA device code requires us to know the host toolchain, because CUDA device-side compiles pull in e.g. host headers. When we only supported Linux compilation, this worked because CudaToolChain, which is responsible for device-side CUDA compilation, inherited from the Linux toolchain. But in order to support MacOS, CudaToolChain needs to take a HostToolChain pointer. Because a CUDA toolchain now requires a host TC, we no longer will create a CUDA toolchain from Driver::getToolChain -- you have to go through CreateOffloadingDeviceToolChains. I am *pretty* sure this is correct, and that previously any attempt to create a CUDA toolchain through getToolChain() would eventually have resulted in us throwing "error: unsupported use of NVPTX for host compilation". In any case hacking getToolChain to create a CUDA+host toolchain would be wrong, because a Driver can be reused for multiple compilations, potentially with different host TCs, and getToolChain will cache the result, causing us to potentially use a stale host TC. So that's the main change in this patch. In addition, we have to pull CudaInstallationDetector out of Generic_GCC and into a top-level class. It's now used by the Generic_GCC and MachO toolchains. Reviewers: tra Subscribers: rryan, hfinkel, sfantao Differential Revision: https://reviews.llvm.org/D26774 llvm-svn: 287285
2016-11-18 08:41:22 +08:00
// RUN: %clang -v --target=i386-apple-macosx \
// RUN: --cuda-path=%S/Inputs/CUDA/usr/local/cuda 2>&1 | FileCheck %s
[CUDA] Added CUDA installation detector class. Added new option --cuda-path=<path> which allows overriding default search paths. If it's not specified we look for CUDA installation in /usr/include/cuda and /usr/include/cuda-7.0. Differential Revision: http://reviews.llvm.org/D12989 llvm-svn: 248433
2015-09-24 05:49:39 +08:00
[CUDA] Require libdevice only if needed If the user passes -nocudalib, we can live without it being present. Simplify the code by just checking whether LibDeviceMap is empty. Differential Revision: https://reviews.llvm.org/D38901 llvm-svn: 315902
2017-10-16 21:31:30 +08:00
// Check that we don't find a CUDA installation without libdevice ...
// RUN: %clang -v --target=i386-unknown-linux \
[CUDA] Detect installation in PATH If the CUDA toolkit is not installed to its default locations in /usr/local/cuda, the user is forced to specify --cuda-path. This is tedious and the driver can be smarter if well-known tools (like ptxas) can already be found in the PATH environment variable. Add option --cuda-path-ignore-env if the user wants to ignore set environment variables. Also use it in the tests to make sure the driver always finds the same CUDA installation, regardless of the user's environment. Differential Revision: https://reviews.llvm.org/D42642 llvm-svn: 323848
2018-01-31 16:26:51 +08:00
// RUN: --sysroot=%S/Inputs/CUDA-nolibdevice --cuda-path-ignore-env 2>&1 | FileCheck %s -check-prefix NOCUDA
[CUDA] Require libdevice only if needed If the user passes -nocudalib, we can live without it being present. Simplify the code by just checking whether LibDeviceMap is empty. Differential Revision: https://reviews.llvm.org/D38901 llvm-svn: 315902
2017-10-16 21:31:30 +08:00
// RUN: %clang -v --target=i386-apple-macosx \
[CUDA] Detect installation in PATH If the CUDA toolkit is not installed to its default locations in /usr/local/cuda, the user is forced to specify --cuda-path. This is tedious and the driver can be smarter if well-known tools (like ptxas) can already be found in the PATH environment variable. Add option --cuda-path-ignore-env if the user wants to ignore set environment variables. Also use it in the tests to make sure the driver always finds the same CUDA installation, regardless of the user's environment. Differential Revision: https://reviews.llvm.org/D42642 llvm-svn: 323848
2018-01-31 16:26:51 +08:00
// RUN: --sysroot=%S/Inputs/CUDA-nolibdevice --cuda-path-ignore-env 2>&1 | FileCheck %s -check-prefix NOCUDA
// RUN: %clang -v --target=x86_64-unknown-linux \
// RUN: --sysroot=%S/Inputs/CUDA-nolibdevice --cuda-path-ignore-env 2>&1 | FileCheck %s -check-prefix NOCUDA
// RUN: %clang -v --target=x84_64-apple-macosx \
// RUN: --sysroot=%S/Inputs/CUDA-nolibdevice --cuda-path-ignore-env 2>&1 | FileCheck %s -check-prefix NOCUDA
[CUDA] Require libdevice only if needed If the user passes -nocudalib, we can live without it being present. Simplify the code by just checking whether LibDeviceMap is empty. Differential Revision: https://reviews.llvm.org/D38901 llvm-svn: 315902
2017-10-16 21:31:30 +08:00
// ... unless the user doesn't need libdevice
// RUN: %clang -v --target=i386-unknown-linux -nocudalib \
[CUDA] Detect installation in PATH If the CUDA toolkit is not installed to its default locations in /usr/local/cuda, the user is forced to specify --cuda-path. This is tedious and the driver can be smarter if well-known tools (like ptxas) can already be found in the PATH environment variable. Add option --cuda-path-ignore-env if the user wants to ignore set environment variables. Also use it in the tests to make sure the driver always finds the same CUDA installation, regardless of the user's environment. Differential Revision: https://reviews.llvm.org/D42642 llvm-svn: 323848
2018-01-31 16:26:51 +08:00
// RUN: --sysroot=%S/Inputs/CUDA-nolibdevice --cuda-path-ignore-env 2>&1 | FileCheck %s -check-prefix NO-LIBDEVICE
[CUDA] Require libdevice only if needed If the user passes -nocudalib, we can live without it being present. Simplify the code by just checking whether LibDeviceMap is empty. Differential Revision: https://reviews.llvm.org/D38901 llvm-svn: 315902
2017-10-16 21:31:30 +08:00
// RUN: %clang -v --target=i386-apple-macosx -nocudalib \
[CUDA] Detect installation in PATH If the CUDA toolkit is not installed to its default locations in /usr/local/cuda, the user is forced to specify --cuda-path. This is tedious and the driver can be smarter if well-known tools (like ptxas) can already be found in the PATH environment variable. Add option --cuda-path-ignore-env if the user wants to ignore set environment variables. Also use it in the tests to make sure the driver always finds the same CUDA installation, regardless of the user's environment. Differential Revision: https://reviews.llvm.org/D42642 llvm-svn: 323848
2018-01-31 16:26:51 +08:00
// RUN: --sysroot=%S/Inputs/CUDA-nolibdevice --cuda-path-ignore-env 2>&1 | FileCheck %s -check-prefix NO-LIBDEVICE
// RUN: %clang -v --target=x86_64-unknown-linux -nocudalib \
// RUN: --sysroot=%S/Inputs/CUDA-nolibdevice --cuda-path-ignore-env 2>&1 | FileCheck %s -check-prefix NO-LIBDEVICE
// RUN: %clang -v --target=x86_64-apple-macosx -nocudalib \
// RUN: --sysroot=%S/Inputs/CUDA-nolibdevice --cuda-path-ignore-env 2>&1 | FileCheck %s -check-prefix NO-LIBDEVICE
[CUDA] Require libdevice only if needed If the user passes -nocudalib, we can live without it being present. Simplify the code by just checking whether LibDeviceMap is empty. Differential Revision: https://reviews.llvm.org/D38901 llvm-svn: 315902
2017-10-16 21:31:30 +08:00
[CUDA] Fix libdevice selection. This makes clang's libdevice selection match that of NVCC as described in http://docs.nvidia.com/cuda/libdevice-users-guide/basic-usage.html#version-selection If required libdevice variant is not found, driver now fails with an error. Differential Revision: https://reviews.llvm.org/D23037 llvm-svn: 277542
2016-08-03 07:12:51 +08:00
// Make sure we map libdevice bitcode files to proper GPUs. These
// tests use Inputs/CUDA_80 which has full set of libdevice files.
// However, libdevice mapping only matches CUDA-7.x at the moment.
// sm_2x, sm_32 -> compute_20
[CUDA] Detect and link with CUDA's libdevice bitcode library. - added detection of libdevice bitcode file and API to find one appropriate for the GPU we're compiling for. - pass additional cc1 options for linking with detected libdevice bitcode - added -nocudalib to prevent automatic linking with libdevice - added test cases to verify new functionality Differential Revision: http://reviews.llvm.org/D14556 llvm-svn: 253387
2015-11-18 06:28:50 +08:00
// RUN: %clang -### -v --target=i386-unknown-linux --cuda-gpu-arch=sm_21 \
[CUDA] Fix libdevice selection. This makes clang's libdevice selection match that of NVCC as described in http://docs.nvidia.com/cuda/libdevice-users-guide/basic-usage.html#version-selection If required libdevice variant is not found, driver now fails with an error. Differential Revision: https://reviews.llvm.org/D23037 llvm-svn: 277542
2016-08-03 07:12:51 +08:00
// RUN: --cuda-path=%S/Inputs/CUDA_80/usr/local/cuda %s 2>&1 \
// RUN: | FileCheck %s -check-prefix COMMON \
// RUN: -check-prefix LIBDEVICE -check-prefix LIBDEVICE20
// RUN: %clang -### -v --target=i386-unknown-linux --cuda-gpu-arch=sm_32 \
// RUN: --cuda-path=%S/Inputs/CUDA_80/usr/local/cuda %s 2>&1 \
// RUN: | FileCheck %s -check-prefix COMMON \
// RUN: -check-prefix LIBDEVICE -check-prefix LIBDEVICE20
[CUDA] Added support for CUDA-8 Differential Revision: https://reviews.llvm.org/D24946 llvm-svn: 282610
2016-09-29 01:47:40 +08:00
// sm_30, sm_6x map to compute_30.
[CUDA] Fix libdevice selection. This makes clang's libdevice selection match that of NVCC as described in http://docs.nvidia.com/cuda/libdevice-users-guide/basic-usage.html#version-selection If required libdevice variant is not found, driver now fails with an error. Differential Revision: https://reviews.llvm.org/D23037 llvm-svn: 277542
2016-08-03 07:12:51 +08:00
// RUN: %clang -### -v --target=i386-unknown-linux --cuda-gpu-arch=sm_30 \
// RUN: --cuda-path=%S/Inputs/CUDA_80/usr/local/cuda %s 2>&1 \
[CUDA] Detect and link with CUDA's libdevice bitcode library. - added detection of libdevice bitcode file and API to find one appropriate for the GPU we're compiling for. - pass additional cc1 options for linking with detected libdevice bitcode - added -nocudalib to prevent automatic linking with libdevice - added test cases to verify new functionality Differential Revision: http://reviews.llvm.org/D14556 llvm-svn: 253387
2015-11-18 06:28:50 +08:00
// RUN: | FileCheck %s -check-prefix COMMON \
[CUDA] Fix libdevice selection. This makes clang's libdevice selection match that of NVCC as described in http://docs.nvidia.com/cuda/libdevice-users-guide/basic-usage.html#version-selection If required libdevice variant is not found, driver now fails with an error. Differential Revision: https://reviews.llvm.org/D23037 llvm-svn: 277542
2016-08-03 07:12:51 +08:00
// RUN: -check-prefix LIBDEVICE -check-prefix LIBDEVICE30
[CUDA] Added support for CUDA-8 Differential Revision: https://reviews.llvm.org/D24946 llvm-svn: 282610
2016-09-29 01:47:40 +08:00
// sm_5x is a special case. Maps to compute_30 for cuda-7.x only.
[CUDA] Fix libdevice selection. This makes clang's libdevice selection match that of NVCC as described in http://docs.nvidia.com/cuda/libdevice-users-guide/basic-usage.html#version-selection If required libdevice variant is not found, driver now fails with an error. Differential Revision: https://reviews.llvm.org/D23037 llvm-svn: 277542
2016-08-03 07:12:51 +08:00
// RUN: %clang -### -v --target=i386-unknown-linux --cuda-gpu-arch=sm_50 \
[CUDA] Added support for CUDA-8 Differential Revision: https://reviews.llvm.org/D24946 llvm-svn: 282610
2016-09-29 01:47:40 +08:00
// RUN: --cuda-path=%S/Inputs/CUDA/usr/local/cuda %s 2>&1 \
[CUDA] Fix libdevice selection. This makes clang's libdevice selection match that of NVCC as described in http://docs.nvidia.com/cuda/libdevice-users-guide/basic-usage.html#version-selection If required libdevice variant is not found, driver now fails with an error. Differential Revision: https://reviews.llvm.org/D23037 llvm-svn: 277542
2016-08-03 07:12:51 +08:00
// RUN: | FileCheck %s -check-prefix COMMON \
// RUN: -check-prefix LIBDEVICE -check-prefix LIBDEVICE30
// RUN: %clang -### -v --target=i386-unknown-linux --cuda-gpu-arch=sm_60 \
// RUN: --cuda-path=%S/Inputs/CUDA_80/usr/local/cuda %s 2>&1 \
// RUN: | FileCheck %s -check-prefix COMMON \
// RUN: -check-prefix LIBDEVICE -check-prefix LIBDEVICE30
// sm_35 and sm_37 -> compute_35
[CUDA] added include paths for both sides of CUDA compilation. In order to compile a CUDA file clang must be able to find include files for both both host and device. This patch passes AuxToolchain to AddPreprocessingOptions and uses it to add include paths for the opposite side of compilation. We also must be able to find CUDA include files. If the driver found CUDA installation, it adds appropriate include path to CUDA headers. This can be disabled with '-nocudainc'. - Added include paths for the opposite side of compilation. - Added include paths to detected CUDA installation. - Added -nocudainc to prevent adding CUDA include path. - Added test cases to verify new functionality. Differential Revision: http://reviews.llvm.org/D13170 llvm-svn: 253386
2015-11-18 06:28:46 +08:00
// RUN: %clang -### -v --target=i386-unknown-linux --cuda-gpu-arch=sm_35 \
[CUDA] Fix libdevice selection. This makes clang's libdevice selection match that of NVCC as described in http://docs.nvidia.com/cuda/libdevice-users-guide/basic-usage.html#version-selection If required libdevice variant is not found, driver now fails with an error. Differential Revision: https://reviews.llvm.org/D23037 llvm-svn: 277542
2016-08-03 07:12:51 +08:00
// RUN: --cuda-path=%S/Inputs/CUDA_80/usr/local/cuda %s 2>&1 \
[CUDA] Detect and link with CUDA's libdevice bitcode library. - added detection of libdevice bitcode file and API to find one appropriate for the GPU we're compiling for. - pass additional cc1 options for linking with detected libdevice bitcode - added -nocudalib to prevent automatic linking with libdevice - added test cases to verify new functionality Differential Revision: http://reviews.llvm.org/D14556 llvm-svn: 253387
2015-11-18 06:28:50 +08:00
// RUN: | FileCheck %s -check-prefix COMMON -check-prefix CUDAINC \
// RUN: -check-prefix LIBDEVICE -check-prefix LIBDEVICE35
[CUDA] Fix libdevice selection. This makes clang's libdevice selection match that of NVCC as described in http://docs.nvidia.com/cuda/libdevice-users-guide/basic-usage.html#version-selection If required libdevice variant is not found, driver now fails with an error. Differential Revision: https://reviews.llvm.org/D23037 llvm-svn: 277542
2016-08-03 07:12:51 +08:00
// RUN: %clang -### -v --target=i386-unknown-linux --cuda-gpu-arch=sm_37 \
// RUN: --cuda-path=%S/Inputs/CUDA_80/usr/local/cuda %s 2>&1 \
// RUN: | FileCheck %s -check-prefix COMMON -check-prefix CUDAINC \
// RUN: -check-prefix LIBDEVICE -check-prefix LIBDEVICE35
[CUDA] Added support for CUDA-8 Differential Revision: https://reviews.llvm.org/D24946 llvm-svn: 282610
2016-09-29 01:47:40 +08:00
// sm_5x -> compute_50 for CUDA-8.0 and newer.
// RUN: %clang -### -v --target=i386-unknown-linux --cuda-gpu-arch=sm_50 \
// RUN: --cuda-path=%S/Inputs/CUDA_80/usr/local/cuda %s 2>&1 \
// RUN: | FileCheck %s -check-prefix COMMON \
// RUN: -check-prefix LIBDEVICE -check-prefix LIBDEVICE50
[CUDA] Detect and link with CUDA's libdevice bitcode library. - added detection of libdevice bitcode file and API to find one appropriate for the GPU we're compiling for. - pass additional cc1 options for linking with detected libdevice bitcode - added -nocudalib to prevent automatic linking with libdevice - added test cases to verify new functionality Differential Revision: http://reviews.llvm.org/D14556 llvm-svn: 253387
2015-11-18 06:28:50 +08:00
// Verify that -nocudainc prevents adding include path to CUDA headers.
[CUDA] added include paths for both sides of CUDA compilation. In order to compile a CUDA file clang must be able to find include files for both both host and device. This patch passes AuxToolchain to AddPreprocessingOptions and uses it to add include paths for the opposite side of compilation. We also must be able to find CUDA include files. If the driver found CUDA installation, it adds appropriate include path to CUDA headers. This can be disabled with '-nocudainc'. - Added include paths for the opposite side of compilation. - Added include paths to detected CUDA installation. - Added -nocudainc to prevent adding CUDA include path. - Added test cases to verify new functionality. Differential Revision: http://reviews.llvm.org/D13170 llvm-svn: 253386
2015-11-18 06:28:46 +08:00
// RUN: %clang -### -v --target=i386-unknown-linux --cuda-gpu-arch=sm_35 \
// RUN: -nocudainc --cuda-path=%S/Inputs/CUDA/usr/local/cuda %s 2>&1 \
[CUDA] Detect and link with CUDA's libdevice bitcode library. - added detection of libdevice bitcode file and API to find one appropriate for the GPU we're compiling for. - pass additional cc1 options for linking with detected libdevice bitcode - added -nocudalib to prevent automatic linking with libdevice - added test cases to verify new functionality Differential Revision: http://reviews.llvm.org/D14556 llvm-svn: 253387
2015-11-18 06:28:50 +08:00
// RUN: | FileCheck %s -check-prefix COMMON -check-prefix NOCUDAINC \
// RUN: -check-prefix LIBDEVICE -check-prefix LIBDEVICE35
[CUDA] Driver changes to support CUDA compilation on MacOS. Summary: Compiling CUDA device code requires us to know the host toolchain, because CUDA device-side compiles pull in e.g. host headers. When we only supported Linux compilation, this worked because CudaToolChain, which is responsible for device-side CUDA compilation, inherited from the Linux toolchain. But in order to support MacOS, CudaToolChain needs to take a HostToolChain pointer. Because a CUDA toolchain now requires a host TC, we no longer will create a CUDA toolchain from Driver::getToolChain -- you have to go through CreateOffloadingDeviceToolChains. I am *pretty* sure this is correct, and that previously any attempt to create a CUDA toolchain through getToolChain() would eventually have resulted in us throwing "error: unsupported use of NVPTX for host compilation". In any case hacking getToolChain to create a CUDA+host toolchain would be wrong, because a Driver can be reused for multiple compilations, potentially with different host TCs, and getToolChain will cache the result, causing us to potentially use a stale host TC. So that's the main change in this patch. In addition, we have to pull CudaInstallationDetector out of Generic_GCC and into a top-level class. It's now used by the Generic_GCC and MachO toolchains. Reviewers: tra Subscribers: rryan, hfinkel, sfantao Differential Revision: https://reviews.llvm.org/D26774 llvm-svn: 287285
2016-11-18 08:41:22 +08:00
// RUN: %clang -### -v --target=i386-apple-macosx --cuda-gpu-arch=sm_35 \
// RUN: -nocudainc --cuda-path=%S/Inputs/CUDA/usr/local/cuda %s 2>&1 \
// RUN: | FileCheck %s -check-prefix COMMON -check-prefix NOCUDAINC \
// RUN: -check-prefix LIBDEVICE -check-prefix LIBDEVICE35
[CUDA] added include paths for both sides of CUDA compilation. In order to compile a CUDA file clang must be able to find include files for both both host and device. This patch passes AuxToolchain to AddPreprocessingOptions and uses it to add include paths for the opposite side of compilation. We also must be able to find CUDA include files. If the driver found CUDA installation, it adds appropriate include path to CUDA headers. This can be disabled with '-nocudainc'. - Added include paths for the opposite side of compilation. - Added include paths to detected CUDA installation. - Added -nocudainc to prevent adding CUDA include path. - Added test cases to verify new functionality. Differential Revision: http://reviews.llvm.org/D13170 llvm-svn: 253386
2015-11-18 06:28:46 +08:00
// We should not add any CUDA include paths if there's no valid CUDA installation
// RUN: %clang -### -v --target=i386-unknown-linux --cuda-gpu-arch=sm_35 \
// RUN: --cuda-path=%S/no-cuda-there %s 2>&1 \
// RUN: | FileCheck %s -check-prefix COMMON -check-prefix NOCUDAINC
[CUDA] Driver changes to support CUDA compilation on MacOS. Summary: Compiling CUDA device code requires us to know the host toolchain, because CUDA device-side compiles pull in e.g. host headers. When we only supported Linux compilation, this worked because CudaToolChain, which is responsible for device-side CUDA compilation, inherited from the Linux toolchain. But in order to support MacOS, CudaToolChain needs to take a HostToolChain pointer. Because a CUDA toolchain now requires a host TC, we no longer will create a CUDA toolchain from Driver::getToolChain -- you have to go through CreateOffloadingDeviceToolChains. I am *pretty* sure this is correct, and that previously any attempt to create a CUDA toolchain through getToolChain() would eventually have resulted in us throwing "error: unsupported use of NVPTX for host compilation". In any case hacking getToolChain to create a CUDA+host toolchain would be wrong, because a Driver can be reused for multiple compilations, potentially with different host TCs, and getToolChain will cache the result, causing us to potentially use a stale host TC. So that's the main change in this patch. In addition, we have to pull CudaInstallationDetector out of Generic_GCC and into a top-level class. It's now used by the Generic_GCC and MachO toolchains. Reviewers: tra Subscribers: rryan, hfinkel, sfantao Differential Revision: https://reviews.llvm.org/D26774 llvm-svn: 287285
2016-11-18 08:41:22 +08:00
// RUN: %clang -### -v --target=i386-apple-macosx --cuda-gpu-arch=sm_35 \
// RUN: --cuda-path=%S/no-cuda-there %s 2>&1 \
// RUN: | FileCheck %s -check-prefix COMMON -check-prefix NOCUDAINC
[CUDA] added include paths for both sides of CUDA compilation. In order to compile a CUDA file clang must be able to find include files for both both host and device. This patch passes AuxToolchain to AddPreprocessingOptions and uses it to add include paths for the opposite side of compilation. We also must be able to find CUDA include files. If the driver found CUDA installation, it adds appropriate include path to CUDA headers. This can be disabled with '-nocudainc'. - Added include paths for the opposite side of compilation. - Added include paths to detected CUDA installation. - Added -nocudainc to prevent adding CUDA include path. - Added test cases to verify new functionality. Differential Revision: http://reviews.llvm.org/D13170 llvm-svn: 253386
2015-11-18 06:28:46 +08:00
[CUDA] Fix libdevice selection. This makes clang's libdevice selection match that of NVCC as described in http://docs.nvidia.com/cuda/libdevice-users-guide/basic-usage.html#version-selection If required libdevice variant is not found, driver now fails with an error. Differential Revision: https://reviews.llvm.org/D23037 llvm-svn: 277542
2016-08-03 07:12:51 +08:00
// Verify that we get an error if there's no libdevice library to link with.
[CUDA] Added support for CUDA-8 Differential Revision: https://reviews.llvm.org/D24946 llvm-svn: 282610
2016-09-29 01:47:40 +08:00
// NOTE: Inputs/CUDA deliberately does *not* have libdevice.compute_20 for this purpose.
// RUN: %clang -### -v --target=i386-unknown-linux --cuda-gpu-arch=sm_20 \
[CUDA] Detect and link with CUDA's libdevice bitcode library. - added detection of libdevice bitcode file and API to find one appropriate for the GPU we're compiling for. - pass additional cc1 options for linking with detected libdevice bitcode - added -nocudalib to prevent automatic linking with libdevice - added test cases to verify new functionality Differential Revision: http://reviews.llvm.org/D14556 llvm-svn: 253387
2015-11-18 06:28:50 +08:00
// RUN: --cuda-path=%S/Inputs/CUDA/usr/local/cuda %s 2>&1 \
[CUDA] Fix libdevice selection. This makes clang's libdevice selection match that of NVCC as described in http://docs.nvidia.com/cuda/libdevice-users-guide/basic-usage.html#version-selection If required libdevice variant is not found, driver now fails with an error. Differential Revision: https://reviews.llvm.org/D23037 llvm-svn: 277542
2016-08-03 07:12:51 +08:00
// RUN: | FileCheck %s -check-prefix COMMON -check-prefix MISSINGLIBDEVICE
[CUDA] Driver changes to support CUDA compilation on MacOS. Summary: Compiling CUDA device code requires us to know the host toolchain, because CUDA device-side compiles pull in e.g. host headers. When we only supported Linux compilation, this worked because CudaToolChain, which is responsible for device-side CUDA compilation, inherited from the Linux toolchain. But in order to support MacOS, CudaToolChain needs to take a HostToolChain pointer. Because a CUDA toolchain now requires a host TC, we no longer will create a CUDA toolchain from Driver::getToolChain -- you have to go through CreateOffloadingDeviceToolChains. I am *pretty* sure this is correct, and that previously any attempt to create a CUDA toolchain through getToolChain() would eventually have resulted in us throwing "error: unsupported use of NVPTX for host compilation". In any case hacking getToolChain to create a CUDA+host toolchain would be wrong, because a Driver can be reused for multiple compilations, potentially with different host TCs, and getToolChain will cache the result, causing us to potentially use a stale host TC. So that's the main change in this patch. In addition, we have to pull CudaInstallationDetector out of Generic_GCC and into a top-level class. It's now used by the Generic_GCC and MachO toolchains. Reviewers: tra Subscribers: rryan, hfinkel, sfantao Differential Revision: https://reviews.llvm.org/D26774 llvm-svn: 287285
2016-11-18 08:41:22 +08:00
// RUN: %clang -### -v --target=i386-apple-macosx --cuda-gpu-arch=sm_20 \
// RUN: --cuda-path=%S/Inputs/CUDA/usr/local/cuda %s 2>&1 \
// RUN: | FileCheck %s -check-prefix COMMON -check-prefix MISSINGLIBDEVICE
[CUDA] Fix libdevice selection. This makes clang's libdevice selection match that of NVCC as described in http://docs.nvidia.com/cuda/libdevice-users-guide/basic-usage.html#version-selection If required libdevice variant is not found, driver now fails with an error. Differential Revision: https://reviews.llvm.org/D23037 llvm-svn: 277542
2016-08-03 07:12:51 +08:00
// Verify that -nocudalib prevents linking libdevice bitcode in.
[CUDA] Detect and link with CUDA's libdevice bitcode library. - added detection of libdevice bitcode file and API to find one appropriate for the GPU we're compiling for. - pass additional cc1 options for linking with detected libdevice bitcode - added -nocudalib to prevent automatic linking with libdevice - added test cases to verify new functionality Differential Revision: http://reviews.llvm.org/D14556 llvm-svn: 253387
2015-11-18 06:28:50 +08:00
// RUN: %clang -### -v --target=i386-unknown-linux --cuda-gpu-arch=sm_35 \
// RUN: -nocudalib --cuda-path=%S/Inputs/CUDA/usr/local/cuda %s 2>&1 \
// RUN: | FileCheck %s -check-prefix COMMON -check-prefix NOLIBDEVICE
[CUDA] Driver changes to support CUDA compilation on MacOS. Summary: Compiling CUDA device code requires us to know the host toolchain, because CUDA device-side compiles pull in e.g. host headers. When we only supported Linux compilation, this worked because CudaToolChain, which is responsible for device-side CUDA compilation, inherited from the Linux toolchain. But in order to support MacOS, CudaToolChain needs to take a HostToolChain pointer. Because a CUDA toolchain now requires a host TC, we no longer will create a CUDA toolchain from Driver::getToolChain -- you have to go through CreateOffloadingDeviceToolChains. I am *pretty* sure this is correct, and that previously any attempt to create a CUDA toolchain through getToolChain() would eventually have resulted in us throwing "error: unsupported use of NVPTX for host compilation". In any case hacking getToolChain to create a CUDA+host toolchain would be wrong, because a Driver can be reused for multiple compilations, potentially with different host TCs, and getToolChain will cache the result, causing us to potentially use a stale host TC. So that's the main change in this patch. In addition, we have to pull CudaInstallationDetector out of Generic_GCC and into a top-level class. It's now used by the Generic_GCC and MachO toolchains. Reviewers: tra Subscribers: rryan, hfinkel, sfantao Differential Revision: https://reviews.llvm.org/D26774 llvm-svn: 287285
2016-11-18 08:41:22 +08:00
// RUN: %clang -### -v --target=i386-apple-macosx --cuda-gpu-arch=sm_35 \
// RUN: -nocudalib --cuda-path=%S/Inputs/CUDA/usr/local/cuda %s 2>&1 \
// RUN: | FileCheck %s -check-prefix COMMON -check-prefix NOLIBDEVICE
[CUDA] Make CUDA compilation usable by default. Currently clang requires several additional command line options in order to enable new features needed during CUDA compilation. This patch makes these options default. * Automatically include cuda_runtime.h if we've found a valid CUDA installation. * Disable automatic CUDA header inclusion during unit tests. * Added test case for command line construction. * Enabled target overloads and relaxed call checks that are needed in order to include CUDA headers. * Added CUDA-7.5 installation path to the CUDA installation search list. * Define __CUDA__ macro to indicate CUDA compilation. llvm-svn: 253389
2015-11-18 06:28:55 +08:00
// Verify that we don't add include paths, link with libdevice or
[CUDA] renamed cuda_runtime.h wrapper to __cuda_runtime.h Currently it's easy to break CUDA compilation by passing "-isystem /path/to/cuda/include" to compiler which leads to compiler including real cuda_runtime.h from there instead of the wrapper we need. Renaming the wrapper ensures that we can include the wrapper regardless of user-specified include paths and files. Differential Revision: http://reviews.llvm.org/D15534 llvm-svn: 255802
2015-12-17 02:51:59 +08:00
// -include __clang_cuda_runtime_wrapper.h without valid CUDA installation.
[CUDA] Make CUDA compilation usable by default. Currently clang requires several additional command line options in order to enable new features needed during CUDA compilation. This patch makes these options default. * Automatically include cuda_runtime.h if we've found a valid CUDA installation. * Disable automatic CUDA header inclusion during unit tests. * Added test case for command line construction. * Enabled target overloads and relaxed call checks that are needed in order to include CUDA headers. * Added CUDA-7.5 installation path to the CUDA installation search list. * Define __CUDA__ macro to indicate CUDA compilation. llvm-svn: 253389
2015-11-18 06:28:55 +08:00
// RUN: %clang -### -v --target=i386-unknown-linux --cuda-gpu-arch=sm_35 \
// RUN: --cuda-path=%S/no-cuda-there %s 2>&1 \
// RUN: | FileCheck %s -check-prefix COMMON \
// RUN: -check-prefix NOCUDAINC -check-prefix NOLIBDEVICE
[CUDA] Driver changes to support CUDA compilation on MacOS. Summary: Compiling CUDA device code requires us to know the host toolchain, because CUDA device-side compiles pull in e.g. host headers. When we only supported Linux compilation, this worked because CudaToolChain, which is responsible for device-side CUDA compilation, inherited from the Linux toolchain. But in order to support MacOS, CudaToolChain needs to take a HostToolChain pointer. Because a CUDA toolchain now requires a host TC, we no longer will create a CUDA toolchain from Driver::getToolChain -- you have to go through CreateOffloadingDeviceToolChains. I am *pretty* sure this is correct, and that previously any attempt to create a CUDA toolchain through getToolChain() would eventually have resulted in us throwing "error: unsupported use of NVPTX for host compilation". In any case hacking getToolChain to create a CUDA+host toolchain would be wrong, because a Driver can be reused for multiple compilations, potentially with different host TCs, and getToolChain will cache the result, causing us to potentially use a stale host TC. So that's the main change in this patch. In addition, we have to pull CudaInstallationDetector out of Generic_GCC and into a top-level class. It's now used by the Generic_GCC and MachO toolchains. Reviewers: tra Subscribers: rryan, hfinkel, sfantao Differential Revision: https://reviews.llvm.org/D26774 llvm-svn: 287285
2016-11-18 08:41:22 +08:00
// RUN: %clang -### -v --target=i386-apple-macosx --cuda-gpu-arch=sm_35 \
// RUN: --cuda-path=%S/no-cuda-there %s 2>&1 \
// RUN: | FileCheck %s -check-prefix COMMON \
// RUN: -check-prefix NOCUDAINC -check-prefix NOLIBDEVICE
[CUDA] Detect and link with CUDA's libdevice bitcode library. - added detection of libdevice bitcode file and API to find one appropriate for the GPU we're compiling for. - pass additional cc1 options for linking with detected libdevice bitcode - added -nocudalib to prevent automatic linking with libdevice - added test cases to verify new functionality Differential Revision: http://reviews.llvm.org/D14556 llvm-svn: 253387
2015-11-18 06:28:50 +08:00
[CUDA] Regression test to make sure C++ include path are forwarded to host and device frontends. Summary: Add test to detect the C++ include paths are passed to both CUDA host and device frontends. Reviewers: tra Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D22946 llvm-svn: 278140
2016-08-10 01:27:24 +08:00
// Verify that C++ include paths are passed for both host and device frontends.
Add a missing -no-canonical-prefixes. llvm-svn: 278148
2016-08-10 03:20:25 +08:00
// RUN: %clang -### -no-canonical-prefixes -target x86_64-linux-gnu %s \
Reorder stderr redirection in test command. llvm-svn: 278811
2016-08-16 22:38:39 +08:00
// RUN: --stdlib=libstdc++ --sysroot=%S/Inputs/ubuntu_14.04_multiarch_tree2 \
// RUN: --gcc-toolchain="" 2>&1 \
[CUDA] Regression test to make sure C++ include path are forwarded to host and device frontends. Summary: Add test to detect the C++ include paths are passed to both CUDA host and device frontends. Reviewers: tra Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D22946 llvm-svn: 278140
2016-08-10 01:27:24 +08:00
// RUN: | FileCheck %s --check-prefix CHECK-CXXINCLUDE
[CUDA] Propagate detected version of CUDA to cc1 ..and use it to control that parts of CUDA compilation that depend on the specific version of CUDA SDK. This patch has a placeholder for a 'new launch API' support which is in a separate patch. The list will be further extended in the upcoming patch to support CUDA-10.1. Differential Revision: https://reviews.llvm.org/D57487 llvm-svn: 352798
2019-02-01 05:32:24 +08:00
// Verify that CUDA SDK version is propagated to the CC1 compilations.
// RUN: %clang -### -v -target x86_64-linux-gnu --cuda-gpu-arch=sm_50 \
// RUN: --cuda-path=%S/Inputs/CUDA_80/usr/local/cuda %s 2>&1 \
// RUN: | FileCheck %s -check-prefix CUDA80
// Verify that if no version file is found, we report the default of 7.0.
// RUN: %clang -### -v -target x86_64-linux-gnu --cuda-gpu-arch=sm_50 \
// RUN: --cuda-path=%S/Inputs/CUDA/usr/local/cuda %s 2>&1 \
// RUN: | FileCheck %s -check-prefix CUDA70
[CUDA] Added CUDA installation detector class. Added new option --cuda-path=<path> which allows overriding default search paths. If it's not specified we look for CUDA installation in /usr/include/cuda and /usr/include/cuda-7.0. Differential Revision: http://reviews.llvm.org/D12989 llvm-svn: 248433
2015-09-24 05:49:39 +08:00
// CHECK: Found CUDA installation: {{.*}}/Inputs/CUDA/usr/local/cuda
[CUDA] Require libdevice only if needed If the user passes -nocudalib, we can live without it being present. Simplify the code by just checking whether LibDeviceMap is empty. Differential Revision: https://reviews.llvm.org/D38901 llvm-svn: 315902
2017-10-16 21:31:30 +08:00
// NO-LIBDEVICE: Found CUDA installation: {{.*}}/Inputs/CUDA-nolibdevice/usr/local/cuda
[CUDA] Added CUDA installation detector class. Added new option --cuda-path=<path> which allows overriding default search paths. If it's not specified we look for CUDA installation in /usr/include/cuda and /usr/include/cuda-7.0. Differential Revision: http://reviews.llvm.org/D12989 llvm-svn: 248433
2015-09-24 05:49:39 +08:00
// NOCUDA-NOT: Found CUDA installation:
[CUDA] added include paths for both sides of CUDA compilation. In order to compile a CUDA file clang must be able to find include files for both both host and device. This patch passes AuxToolchain to AddPreprocessingOptions and uses it to add include paths for the opposite side of compilation. We also must be able to find CUDA include files. If the driver found CUDA installation, it adds appropriate include path to CUDA headers. This can be disabled with '-nocudainc'. - Added include paths for the opposite side of compilation. - Added include paths to detected CUDA installation. - Added -nocudainc to prevent adding CUDA include path. - Added test cases to verify new functionality. Differential Revision: http://reviews.llvm.org/D13170 llvm-svn: 253386
2015-11-18 06:28:46 +08:00
[CUDA] Added support for CUDA-8 Differential Revision: https://reviews.llvm.org/D24946 llvm-svn: 282610
2016-09-29 01:47:40 +08:00
// MISSINGLIBDEVICE: error: cannot find libdevice for sm_20.
[CUDA] Fix libdevice selection. This makes clang's libdevice selection match that of NVCC as described in http://docs.nvidia.com/cuda/libdevice-users-guide/basic-usage.html#version-selection If required libdevice variant is not found, driver now fails with an error. Differential Revision: https://reviews.llvm.org/D23037 llvm-svn: 277542
2016-08-03 07:12:51 +08:00
[CUDA] added include paths for both sides of CUDA compilation. In order to compile a CUDA file clang must be able to find include files for both both host and device. This patch passes AuxToolchain to AddPreprocessingOptions and uses it to add include paths for the opposite side of compilation. We also must be able to find CUDA include files. If the driver found CUDA installation, it adds appropriate include path to CUDA headers. This can be disabled with '-nocudainc'. - Added include paths for the opposite side of compilation. - Added include paths to detected CUDA installation. - Added -nocudainc to prevent adding CUDA include path. - Added test cases to verify new functionality. Differential Revision: http://reviews.llvm.org/D13170 llvm-svn: 253386
2015-11-18 06:28:46 +08:00
// COMMON: "-triple" "nvptx-nvidia-cuda"
// COMMON-SAME: "-fcuda-is-device"
Rename -mlink-cuda-bitcode to -mlink-builtin-bitcode The same semantics work for OpenCL, and probably any offload language. Keep the old name around as an alias. llvm-svn: 340193
2018-08-21 02:16:48 +08:00
// LIBDEVICE-SAME: "-mlink-builtin-bitcode"
// NOLIBDEVICE-NOT: "-mlink-builtin-bitcode"
[CUDA] Fix libdevice selection. This makes clang's libdevice selection match that of NVCC as described in http://docs.nvidia.com/cuda/libdevice-users-guide/basic-usage.html#version-selection If required libdevice variant is not found, driver now fails with an error. Differential Revision: https://reviews.llvm.org/D23037 llvm-svn: 277542
2016-08-03 07:12:51 +08:00
// LIBDEVICE20-SAME: libdevice.compute_20.10.bc
// LIBDEVICE30-SAME: libdevice.compute_30.10.bc
[CUDA] Detect and link with CUDA's libdevice bitcode library. - added detection of libdevice bitcode file and API to find one appropriate for the GPU we're compiling for. - pass additional cc1 options for linking with detected libdevice bitcode - added -nocudalib to prevent automatic linking with libdevice - added test cases to verify new functionality Differential Revision: http://reviews.llvm.org/D14556 llvm-svn: 253387
2015-11-18 06:28:50 +08:00
// LIBDEVICE35-SAME: libdevice.compute_35.10.bc
[CUDA] Added support for CUDA-8 Differential Revision: https://reviews.llvm.org/D24946 llvm-svn: 282610
2016-09-29 01:47:40 +08:00
// LIBDEVICE50-SAME: libdevice.compute_50.10.bc
[CUDA] Detect and link with CUDA's libdevice bitcode library. - added detection of libdevice bitcode file and API to find one appropriate for the GPU we're compiling for. - pass additional cc1 options for linking with detected libdevice bitcode - added -nocudalib to prevent automatic linking with libdevice - added test cases to verify new functionality Differential Revision: http://reviews.llvm.org/D14556 llvm-svn: 253387
2015-11-18 06:28:50 +08:00
// NOLIBDEVICE-NOT: libdevice.compute_{{.*}}.bc
// LIBDEVICE-SAME: "-target-feature" "+ptx42"
// NOLIBDEVICE-NOT: "-target-feature" "+ptx42"
[CUDA] Fix libdevice selection. This makes clang's libdevice selection match that of NVCC as described in http://docs.nvidia.com/cuda/libdevice-users-guide/basic-usage.html#version-selection If required libdevice variant is not found, driver now fails with an error. Differential Revision: https://reviews.llvm.org/D23037 llvm-svn: 277542
2016-08-03 07:12:51 +08:00
// CUDAINC-SAME: "-internal-isystem" "{{.*}}/Inputs/CUDA{{[_0-9]+}}/usr/local/cuda/include"
[CUDA] added include paths for both sides of CUDA compilation. In order to compile a CUDA file clang must be able to find include files for both both host and device. This patch passes AuxToolchain to AddPreprocessingOptions and uses it to add include paths for the opposite side of compilation. We also must be able to find CUDA include files. If the driver found CUDA installation, it adds appropriate include path to CUDA headers. This can be disabled with '-nocudainc'. - Added include paths for the opposite side of compilation. - Added include paths to detected CUDA installation. - Added -nocudainc to prevent adding CUDA include path. - Added test cases to verify new functionality. Differential Revision: http://reviews.llvm.org/D13170 llvm-svn: 253386
2015-11-18 06:28:46 +08:00
// NOCUDAINC-NOT: "-internal-isystem" "{{.*}}/cuda/include"
[CUDA] renamed cuda_runtime.h wrapper to __cuda_runtime.h Currently it's easy to break CUDA compilation by passing "-isystem /path/to/cuda/include" to compiler which leads to compiler including real cuda_runtime.h from there instead of the wrapper we need. Renaming the wrapper ensures that we can include the wrapper regardless of user-specified include paths and files. Differential Revision: http://reviews.llvm.org/D15534 llvm-svn: 255802
2015-12-17 02:51:59 +08:00
// CUDAINC-SAME: "-include" "__clang_cuda_runtime_wrapper.h"
// NOCUDAINC-NOT: "-include" "__clang_cuda_runtime_wrapper.h"
[CUDA] Include CUDA headers before anything else. Summary: There's no point to --cuda-path if we then go and include /usr/include first. And if you install the right packages, Ubuntu will install (very old) CUDA headers there. Reviewers: tra Subscribers: cfe-commits, Prazek Differential Revision: https://reviews.llvm.org/D23341 llvm-svn: 278734
2016-08-16 04:38:52 +08:00
// -internal-externc-isystem flags must come *after* the cuda include flags,
// because we must search the cuda include directory first.
// CUDAINC-SAME: "-internal-externc-isystem"
[CUDA] added include paths for both sides of CUDA compilation. In order to compile a CUDA file clang must be able to find include files for both both host and device. This patch passes AuxToolchain to AddPreprocessingOptions and uses it to add include paths for the opposite side of compilation. We also must be able to find CUDA include files. If the driver found CUDA installation, it adds appropriate include path to CUDA headers. This can be disabled with '-nocudainc'. - Added include paths for the opposite side of compilation. - Added include paths to detected CUDA installation. - Added -nocudainc to prevent adding CUDA include path. - Added test cases to verify new functionality. Differential Revision: http://reviews.llvm.org/D13170 llvm-svn: 253386
2015-11-18 06:28:46 +08:00
// COMMON-SAME: "-x" "cuda"
[CUDA] Regression test to make sure C++ include path are forwarded to host and device frontends. Summary: Add test to detect the C++ include paths are passed to both CUDA host and device frontends. Reviewers: tra Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D22946 llvm-svn: 278140
2016-08-10 01:27:24 +08:00
// CHECK-CXXINCLUDE: clang{{.*}} "-cc1" "-triple" "nvptx64-nvidia-cuda"
// CHECK-CXXINCLUDE-SAME: {{.*}}"-internal-isystem" "{{.+}}/include/c++/4.8"
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
// CHECK-CXXINCLUDE: clang{{.*}} "-cc1" "-triple" "x86_64-unknown-linux-gnu"
[CUDA] Regression test to make sure C++ include path are forwarded to host and device frontends. Summary: Add test to detect the C++ include paths are passed to both CUDA host and device frontends. Reviewers: tra Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D22946 llvm-svn: 278140
2016-08-10 01:27:24 +08:00
// CHECK-CXXINCLUDE-SAME: {{.*}}"-internal-isystem" "{{.+}}/include/c++/4.8"
// CHECK-CXXINCLUDE: ld{{.*}}"
[CUDA] Propagate detected version of CUDA to cc1 ..and use it to control that parts of CUDA compilation that depend on the specific version of CUDA SDK. This patch has a placeholder for a 'new launch API' support which is in a separate patch. The list will be further extended in the upcoming patch to support CUDA-10.1. Differential Revision: https://reviews.llvm.org/D57487 llvm-svn: 352798
2019-02-01 05:32:24 +08:00
[CUDA] Relax lit test condition after r352798. Clang executable doesn't match clang.* in all test environment. llvm-svn: 352865
2019-02-01 19:36:23 +08:00
// CUDA80: "-cc1" "-triple" "nvptx64-nvidia-cuda"
[CUDA] Propagate detected version of CUDA to cc1 ..and use it to control that parts of CUDA compilation that depend on the specific version of CUDA SDK. This patch has a placeholder for a 'new launch API' support which is in a separate patch. The list will be further extended in the upcoming patch to support CUDA-10.1. Differential Revision: https://reviews.llvm.org/D57487 llvm-svn: 352798
2019-02-01 05:32:24 +08:00
// CUDA80-SAME: -target-sdk-version=8.0
[CUDA] Relax lit test condition after r352798. Clang executable doesn't match clang.* in all test environment. llvm-svn: 352865
2019-02-01 19:36:23 +08:00
// CUDA80: "-cc1" "-triple" "x86_64-unknown-linux-gnu"
[CUDA] Propagate detected version of CUDA to cc1 ..and use it to control that parts of CUDA compilation that depend on the specific version of CUDA SDK. This patch has a placeholder for a 'new launch API' support which is in a separate patch. The list will be further extended in the upcoming patch to support CUDA-10.1. Differential Revision: https://reviews.llvm.org/D57487 llvm-svn: 352798
2019-02-01 05:32:24 +08:00
// CUDA80-SAME: -target-sdk-version=8.0
// CUDA80: ld{{.*}}"
[CUDA] Relax lit test condition after r352798. Clang executable doesn't match clang.* in all test environment. llvm-svn: 352865
2019-02-01 19:36:23 +08:00
// CUDA70: "-cc1" "-triple" "nvptx64-nvidia-cuda"
[CUDA] Propagate detected version of CUDA to cc1 ..and use it to control that parts of CUDA compilation that depend on the specific version of CUDA SDK. This patch has a placeholder for a 'new launch API' support which is in a separate patch. The list will be further extended in the upcoming patch to support CUDA-10.1. Differential Revision: https://reviews.llvm.org/D57487 llvm-svn: 352798
2019-02-01 05:32:24 +08:00
// CUDA70-SAME: -target-sdk-version=7.0
[CUDA] Relax lit test condition after r352798. Clang executable doesn't match clang.* in all test environment. llvm-svn: 352865
2019-02-01 19:36:23 +08:00
// CUDA70: "-cc1" "-triple" "x86_64-unknown-linux-gnu"
[CUDA] Propagate detected version of CUDA to cc1 ..and use it to control that parts of CUDA compilation that depend on the specific version of CUDA SDK. This patch has a placeholder for a 'new launch API' support which is in a separate patch. The list will be further extended in the upcoming patch to support CUDA-10.1. Differential Revision: https://reviews.llvm.org/D57487 llvm-svn: 352798
2019-02-01 05:32:24 +08:00
// CUDA70-SAME: -target-sdk-version=7.0
// CUDA70: ld{{.*}}"