Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.0 2019-02-01T11:36:23+00:00 2019-02-01T11:36:23+00:00 Eric Liu ioeric@google.com 2019-02-01T11:36:23+00:00 urn:sha1:f4b19c00b499e26859d0740dec8aecba34e85cbf Clang executable doesn't match clang.* in all test environment. llvm-svn: 352865 2019-01-31T21:32:24+00:00 Artem Belevich tra@google.com 2019-01-31T21:32:24+00:00 urn:sha1:8fa28a0db058eb53970f7eca3aaf71c86357e478 ..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 2018-09-26T07:07:48+00:00 Jiading Gai jiading.gai@gmail.com 2018-09-26T07:07:48+00:00 urn:sha1:664dd75b42709411bfe4d1d8d248a8f4bf15e4c9 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-08-20T18:16:48+00:00 Matt Arsenault Matthew.Arsenault@amd.com 2018-08-20T18:16:48+00:00 urn:sha1:a13746b7eb5306e77c27a4d1246f765850616e48 The same semantics work for OpenCL, and probably any offload language. Keep the old name around as an alias. llvm-svn: 340193 2018-08-08T22:23:57+00:00 Petr Hosek phosek@chromium.org 2018-08-08T22:23:57+00:00 urn:sha1:7b2745447783faa5f94b6f31377fba9284b2e321 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-01-31T08:26:51+00:00 Jonas Hahnfeld hahnjo@hahnjo.de 2018-01-31T08:26:51+00:00 urn:sha1:7f9c5184239eb61e900ca1b34286bf90acf1fe4d 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 2017-10-16T13:31:30+00:00 Jonas Hahnfeld hahnjo@hahnjo.de 2017-10-16T13:31:30+00:00 urn:sha1:e2c342fc654804a549d9b26f11e3aaf970c87048 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 2016-11-18T00:41:22+00:00 Justin Lebar jlebar@google.com 2016-11-18T00:41:22+00:00 urn:sha1:66c4fd7987d216e91d219e5e8437673a7b0167f8 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-09-28T17:47:40+00:00 Artem Belevich tra@google.com 2016-09-28T17:47:40+00:00 urn:sha1:d4d9dc82529d5788fdf6a18f413584e3aa0b3fd4 Differential Revision: https://reviews.llvm.org/D24946 llvm-svn: 282610 2016-08-16T14:38:39+00:00 Samuel Antao sfantao@us.ibm.com 2016-08-16T14:38:39+00:00 urn:sha1:8de34a9cdba8f7dd9ac4475b777e21773c98750c llvm-svn: 278811