summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/Driver.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Split isUsingLTO() outside of embedBitcodeInObject() and ↵Mehdi Amini2017-01-241-1/+2
| | | | | | | | | | | | | | embedBitcodeMarkerOnly(). Summary: These accessors maps directly to the command line option. Reviewers: steven_wu Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D29065 llvm-svn: 292960
* unique_ptrify Driver::ToolChainsDavid Blaikie2017-01-131-44/+45
| | | | llvm-svn: 291938
* unique_ptrify createDriverOptTableDavid Blaikie2017-01-131-9/+7
| | | | llvm-svn: 291919
* Add AVR target and toolchain to ClangDylan McKay2017-01-051-0/+3
| | | | | | | | | | | | | | | | | Summary: Authored by Senthil Kumar Selvaraj This patch adds barebones support in Clang for the (experimental) AVR target. It uses the integrated assembler for assembly, and the GNU linker for linking, as lld doesn't know about the target yet. The DataLayout string is the same as the one in AVRTargetMachine.cpp. The alignment specs look wrong to me, as it's an 8 bit target and all types only need 8 bit alignment. Clang failed with a datalayout mismatch error when I tried to change it, so I left it that way for now. Reviewers: rsmith, dylanmckay, cfe-commits, rengolin Subscribers: rengolin, jroelofs, wdng Differential Revision: https://reviews.llvm.org/D27123 llvm-svn: 291082
* [CUDA,Driver] Added --no-cuda-gpu-arch= option.Artem Belevich2016-12-091-8/+22
| | | | | | | | | | This allows us to negate preceding --cuda-gpu-arch=X. This comes handy when user needs to override default flags set for them by the build system. Differential Revision: https://reviews.llvm.org/D27631 llvm-svn: 289287
* [CUDA] Driver changes to support CUDA compilation on MacOS.Justin Lebar2016-11-181-11/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CrashReproducer][Darwin] Suggest attaching .crash diagnostic fileBruno Cardoso Lopes2016-11-171-0/+115
| | | | | | | | | | | | | | | | | | | | | | | In addition to the preprocessed sources file and reproducer script, also point to the .crash diagnostic files on Darwin. Example: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.cpp clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.cache clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.sh clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.crash When no match is found for the .crash, point the user to a directory where those can be found. Example: clang-4.0: note: diagnostic msg: Crash backtrace is located in clang-4.0: note: diagnostic msg: /Users/bruno/Library/Logs/DiagnosticReports/clang-4.0_<YYYY-MM-DD-HHMMSS>_<hostname>.crash clang-4.0: note: diagnostic msg: (choose the .crash file that corresponds to your crash) rdar://problem/27286266 llvm-svn: 287262
* Add a little endian variant of TCE.Pekka Jaaskelainen2016-11-161-0/+3
| | | | llvm-svn: 287112
* [Driver] Infer the correct option to ld64 for -fembed-bitcodeSteven Wu2016-11-161-21/+15
| | | | | | | | | | | | | | | | | | Summary: -fembed-bitcode infers -bitcode_bundle to ld64 but it is not correctly passed when using LTO. LTO is a special case of -fembed-bitcode which it doesn't require embed the bitcode in a special section in the object file but it requires linker to save that as part of the final executable. rdar://problem/29274226 Reviewers: mehdi_amini Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D26690 llvm-svn: 287084
* Rename the version of ConstructJob for multiple outputs to ↵Samuel Antao2016-11-031-1/+1
| | | | | | | | ConstructJobMultipleOutputs. It was causing trouble with the GCC bots. llvm-svn: 285925
* Fix Clang-tidy readability-redundant-string-cstr warningsMalcolm Parsons2016-11-021-5/+4
| | | | | | | | | | Reviewers: aaron.ballman, mehdi_amini, dblaikie Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D26206 llvm-svn: 285799
* [Driver][OpenMP] Add support to create jobs for unbundling actions.Samuel Antao2016-10-271-36/+104
| | | | | | | | | | | | | | | | | | | Summary: This patch adds the support to create jobs for the `OffloadBundlingAction` which will invoke the `clang-offload-bundler` tool to unbundle input files. Unlike other actions, unbundling actions have multiple outputs. Therefore, this patch adds the required changes to have a variant of `Tool::ConstructJob` with multiple outputs. The way the naming of the results is implemented is also slightly modified so that the same action can use a different offloading prefix for each use by the different offloading actions. With this patch, it is possible to compile a functional OpenMP binary with offloading support, even with separate compilation. Reviewers: echristo, tra, jlebar, ABataev, hfinkel Subscribers: mkuron, whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21857 llvm-svn: 285326
* [Driver][OpenMP] Update actions builder to create unbundling action when ↵Samuel Antao2016-10-271-1/+29
| | | | | | | | | | | | | | | | | necessary. Summary: Each time that offloading support is requested by the user and the input file is not a source file, an action `OffloadUnbundlingAction` is created to signal that the input file may contain bundles, so that the proper tool is then invoked to attempt to extract the components of the bundle. This patch adds the logic to create that action in offload action builder. The job creation for the new action will be proposed in a separate patch. Reviewers: echristo, tra, jlebar, ABataev, hfinkel Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21853 llvm-svn: 285324
* [Driver][OpenMP] Update actions builder to create bundling action when ↵Samuel Antao2016-10-271-4/+66
| | | | | | | | | | | | | | | | | necessary. Summary: In order to save the user from dealing with multiple output files (for host and device) while using separate compilation, a new action `OffloadBundlingAction` is used when the last phase is not linking. This action will then result in a job that uses the proposed bundling tool to create a single preprocessed/IR/ASM/Object file from multiple ones. The job creation for the new action will be proposed in a separate patch. Reviewers: echristo, tra, jlebar, ABataev, hfinkel Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21852 llvm-svn: 285323
* [Driver][OpenMP] Add logic for offloading-specific argument translation.Samuel Antao2016-10-271-3/+6
| | | | | | | | | | | | | | | Summary: This patch includes support for argument translation that is specific of a given offloading kind. Additionally, it implements the translation for OpenMP device kinds in the gcc tool chain. With this patch, it is possible to compile a functional OpenMP application with offloading capabilities with no separate compilation. Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21848 llvm-svn: 285320
* [Driver][OpenMP] Build jobs for OpenMP offloading actions for targets using ↵Samuel Antao2016-10-271-6/+10
| | | | | | | | | | | | | | | | | gcc tool chains. Summary: This patch adds logic to create jobs for OpenMP offloading actions by: - tuning the jobs result information to use the offloading prefix even for (device) linking actions. - replacing the device inputs of the host linking jobs by a linker script that embed them in the right sections. Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel Subscribers: mkuron, whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21847 llvm-svn: 285319
* [Driver][OpenMP] Add specialized action builder for OpenMP offloading actions.Samuel Antao2016-10-271-6/+123
| | | | | | | | | | | | | | | | | Summary: This patch adds a new specialized action builder to create OpenMP offloading actions. The specialized builder is added to the action builder already containing the CUDA specialized builder. OpenMP offloading dependences between host and device actions (expressed with OffloadActions) are different that what is used for CUDA: - Device compile action depends on the host compile action - the device frontend extracts the information about the declarations that have to be emitted by looking into the metadata produced by the host frontend. - The host link action depends on the device link actions - the device images are embedded in the host binary at link time. Reviewers: echristo, tra, rsmith, jlebar, ABataev, hfinkel Subscribers: mkuron, whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21845 llvm-svn: 285314
* [Driver][OpenMP] Create tool chains for OpenMP offloading kind.Samuel Antao2016-10-271-0/+79
| | | | | | | | | | | | Summary: This patch adds new logic to create the necessary tool chains to support offloading for OpenMP. The OpenMP related options are checked and the tool chains created accordingly. Diagnostics are emitted in case the options are illegal or express unknown targets. Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel Subscribers: whchung, mkuron, mehdi_amini, cfe-commits, Hahnfeld, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21843 llvm-svn: 285311
* [Driver][CUDA][OpenMP] Reimplement tool selection in the driver.Samuel Antao2016-10-271-126/+272
| | | | | | | | | | | | | | | | | Summary: This creates a tool selector in the driver that replaces the existing one. The goal is to better organize the code and make the selector easier to scale, in particular in the presence of offload actions that can be collapsed. The current implementation became more confusing when the support for offloading actions was added. This concern was expressed by Eric in http://reviews.llvm.org/D9888. This patch does not add new testing, it preserves the existing functionality. Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel Subscribers: whchung, guansong, mkuron, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, caomhin, arpith-jacob, carlo.bertolli Differential Revision: https://reviews.llvm.org/D21840 llvm-svn: 285307
* Remove check for -o option in offloading actions builder.Samuel Antao2016-10-271-18/+1
| | | | | | This check is also present when jobs are built, so the offloading builder check is not needed anymore. llvm-svn: 285264
* Fix bug when compiling CUDA code with -emit-llvm and -o. Samuel Antao2016-10-271-0/+5
| | | | | | | In this case the device code is not injected into an host action and therefore the user should get an error as -o can't be used when generating two outputs. llvm-svn: 285263
* Define Contiki OS toolchainDavid L Kreitzer2016-10-141-0/+3
| | | | | | | | Patch by Michael LeMay Differential revision: http://reviews.llvm.org/D19854 llvm-svn: 284278
* [Driver] Make -print-libgcc-file-name print compiler-rt lib when usedMichal Gorny2016-10-101-1/+9
| | | | | | | | | | | | | | | | | | | | Make the -print-libgcc-file-name option print an appropriate compiler runtime library, that is libgcc.a if gcc runtime is used and an appropriate compiler-rt library if that runtime is used. The main use for this is to allow linking executables built with -nodefaultlibs (e.g. to avoid linking to the standard C++ library) to the compiler runtime library, e.g. using: clang++ ... -nodefaultlibs $(clang++ ... -print-libgcc-file-name) in which case currently a program built like this linked to the gcc runtime unconditionally. The patch fixes it to use compiler-rt libraries instead when compiler-rt is the active runtime. Differential Revision: https://reviews.llvm.org/D25338 llvm-svn: 283746
* Turn ArchName/BoundArch in Driver from raw pointer to StringRef (NFC)Mehdi Amini2016-10-071-9/+9
| | | | llvm-svn: 283605
* Revert r283572 - [Driver] Make -print-libgcc-file-name print compiler-rt lib ↵Michal Gorny2016-10-071-9/+1
| | | | | | | | | | when used Revert the -print-libgcc-file-name change as the new test fails on Darwin. It needs to be updated to run the libgcc part only on systems supporting that rtlib. llvm-svn: 283586
* [Driver] Make -print-libgcc-file-name print compiler-rt lib when usedMichal Gorny2016-10-071-1/+9
| | | | | | | | | | | | | | | | | | | | Make the -print-libgcc-file-name option print an appropriate compiler runtime library, that is libgcc.a if gcc runtime is used and an appropriate compiler-rt library if that runtime is used. The main use for this is to allow linking executables built with -nodefaultlibs (e.g. to avoid linking to the standard C++ library) to the compiler runtime library, e.g. using: clang++ ... -nodefaultlibs $(clang++ ... -print-libgcc-file-name) in which case currently a program built like this linked to the gcc runtime unconditionally. The patch fixes it to use compiler-rt libraries instead when compiler-rt is the active runtime. Differential Revision: https://reviews.llvm.org/D25338 llvm-svn: 283572
* [Driver] Add driver support for FuchsiaPetr Hosek2016-10-061-0/+3
| | | | | | | | | | | Provide toolchain and tool support for Fuchsia operating system. Fuchsia uses compiler-rt as the runtime library and libc++, libc++abi and libunwind as the C++ standard library. lld is used as a default linker. Differential Revision: https://reviews.llvm.org/D25117 llvm-svn: 283420
* Taking StringRef in Driver.h APIs instead of raw pointers (NFC)Mehdi Amini2016-10-061-34/+32
| | | | llvm-svn: 283417
* clang-cl: Make /Fo apply also when using -fltoHans Wennborg2016-10-041-1/+1
| | | | llvm-svn: 283258
* [CUDA][OpenMP] Add a generic offload action builderSamuel Antao2016-09-301-161/+557
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch proposes a new class to generate and record action dependences related with offloading. The builder provides three main functionalities: - Add device dependences to host actions. - Add host dependence to device actions. - Register device top-level actions. The constructor of the builder detect the programming models that should be supported, and generates a specialized builder for each. If a new programming model is to be added in the future, only a new specialized builder has to be implemented. When the specialized builder is generated, it produces programming-model-specific diagnostics. A CUDA specialized builder is proposed in the patch that mostly consists of the partition of the current `buildCudaAction` by the three different functionalities. Reviewers: tra, echristo, ABataev, jlebar, hfinkel Subscribers: Hahnfeld, whchung, guansong, jlebar, mehdi_amini, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D18172 llvm-svn: 282865
* Unrevert r280035 now that the clang-cl bug it exposed has been fixed byRichard Smith2016-08-301-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r280133. Original commit message: C++ Modules TS: driver support for building modules. This works as follows: we add --precompile to the existing gamut of options for specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag specifies that an input is taken to the precompilation step and no further, and this can be specified when building a .pcm from a module interface or when building a .pch from a header file. The .cppm extension (and some related extensions) are implicitly recognized as C++ module interface files. If --precompile is /not/ specified, the file is compiled (via a .pcm) to a .o file containing the code for the module (and then potentially also assembled and linked, if -S, -c, etc. are not specified). We do not yet suppress the emission of object code for other users of the module interface, so for now this will only work if everything in the .cppm file has vague linkage. As with the existing support for module-map modules, prebuilt modules can be provided as compiler inputs either via the -fmodule-file= command-line argument or via files named ModuleName.pcm in one of the directories specified via -fprebuilt-module-path=. This also exposes the -fmodules-ts cc1 flag in the driver. This is still experimental, and in particular, the concrete syntax is subject to change as the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does not enable support for implicitly loading module maps nor building modules via the module cache, but those features can be turned on separately and used in conjunction with the Modules TS support. llvm-svn: 280134
* PR30195: Fix clang-cl attempting to precompile bogus (non-precompilable) ↵Richard Smith2016-08-301-2/+6
| | | | | | input types. llvm-svn: 280133
* Revert r280035 (and followups r280057, r280085), it caused PR30195Nico Weber2016-08-301-11/+3
| | | | llvm-svn: 280091
* C++ Modules TS: driver support for building modules.Richard Smith2016-08-301-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This works as follows: we add --precompile to the existing gamut of options for specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag specifies that an input is taken to the precompilation step and no further, and this can be specified when building a .pcm from a module interface or when building a .pch from a header file. The .cppm extension (and some related extensions) are implicitly recognized as C++ module interface files. If --precompile is /not/ specified, the file is compiled (via a .pcm) to a .o file containing the code for the module (and then potentially also assembled and linked, if -S, -c, etc. are not specified). We do not yet suppress the emission of object code for other users of the module interface, so for now this will only work if everything in the .cppm file has vague linkage. As with the existing support for module-map modules, prebuilt modules can be provided as compiler inputs either via the -fmodule-file= command-line argument or via files named ModuleName.pcm in one of the directories specified via -fprebuilt-module-path=. This also exposes the -fmodules-ts cc1 flag in the driver. This is still experimental, and in particular, the concrete syntax is subject to change as the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does not enable support for implicitly loading module maps nor building modules via the module cache, but those features can be turned on separately and used in conjunction with the Modules TS support. llvm-svn: 280035
* [CUDA] Collapsed offload actions should not be top-level jobs.Artem Belevich2016-08-221-1/+1
| | | | | | | | | | | | If they are, we end up with the last intermediary output preserved in the current directory after compilation. Added a test case to verify that we're using appropriate filenames for outputs of different phases. Differential Revision: https://reviews.llvm.org/D23526 llvm-svn: 279455
* [Driver] Set the default driver mode based on the executable.Zachary Turner2016-08-121-18/+26
| | | | | | | | | | | | | | | | | | Currently, if --driver-mode is not passed at all, it will default to GCC style driver. This is never an issue for clang because it manually constructs a --driver-mode option and passes it. However, we should still try to do as good as we can even if no --driver-mode is passed. LibTooling, for example, does not pass a --driver-mode option and while it could, it seems like we should still fallback to the best possible default we can. This is one of two steps necessary to get clang-tidy working on Windows. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D23454 llvm-svn: 278535
* [CUDA] Do not allow using NVPTX target for host compilation.Artem Belevich2016-08-021-6/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D23042 llvm-svn: 277537
* Retry: [Driver] Compute effective target triples once per job (NFCI)Vedant Kumar2016-07-271-0/+13
| | | | | | | | | | | | | | | | Compute an effective triple once per job. Cache the triple in the prevailing ToolChain for the duration of the job. Clients which need effective triples now look them up in the ToolChain. This eliminates wasteful re-computation of effective triples (e.g in getARMFloatABI()). While we're at it, delete MachO::ComputeEffectiveClangTriple. It was a no-op override. Differential Revision: https://reviews.llvm.org/D22596 llvm-svn: 276937
* Revert "[Driver] Compute effective target triples once per job (NFCI)"Vedant Kumar2016-07-271-15/+1
| | | | | | | This reverts commit r275895 in order to address some post-commit review feedback from Eric Christopher (see: the list thread for r275895). llvm-svn: 276936
* [Driver] Switch some getenv calls to llvm::sys::Process::GetEnvDavid Majnemer2016-07-241-2/+3
| | | | | | No functional change is intended. llvm-svn: 276573
* [Driver] Compute effective target triples once per job (NFCI)Vedant Kumar2016-07-181-1/+15
| | | | | | | | | | Compute an effective target triple exactly once in ConstructJob(), and then simply pass around references to it. This eliminates wasteful re-computation of effective triples (e.g in getARMFloatABI()). Differential Revision: https://reviews.llvm.org/D22290 llvm-svn: 275895
* [Driver] Make Driver::DefaultTargetTriple private (NFCI)Vedant Kumar2016-07-181-3/+3
| | | | | | | | | | | | No in-tree targets access this `DefaultTargetTriple` directly, and usage of default triples is generally discouraged. Make the field private. This is part of en effort to make the clang driver use effective triples more pervasively. Differential Revision: https://reviews.llvm.org/D22289 llvm-svn: 275894
* [NFC] Header cleanupMehdi Amini2016-07-181-1/+0
| | | | | | | | | | Summary: Removed unused headers, replaced some headers with forward class declarations Patch by: Eugene <claprix@yandex.ru> Differential Revision: https://reviews.llvm.org/D20100 llvm-svn: 275882
* [CUDA][OpenMP] Create generic offload actionSamuel Antao2016-07-151-111/+259
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch replaces the CUDA specific action by a generic offload action. The offload action may have multiple dependences classier in “host” and “device”. The way this generic offloading action is used is very similar to what is done today by the CUDA implementation: it is used to set a specific toolchain and architecture to its dependences during the generation of jobs. This patch also proposes propagating the offloading information through the action graph so that that information can be easily retrieved at any time during the generation of commands. This allows e.g. the "clang tool” to evaluate whether CUDA should be supported for the device or host and ptas to easily retrieve the target architecture. This is an example of how the action graphs would look like (compilation of a single CUDA file with two GPU architectures) ``` 0: input, "cudatests.cu", cuda, (host-cuda) 1: preprocessor, {0}, cuda-cpp-output, (host-cuda) 2: compiler, {1}, ir, (host-cuda) 3: input, "cudatests.cu", cuda, (device-cuda, sm_35) 4: preprocessor, {3}, cuda-cpp-output, (device-cuda, sm_35) 5: compiler, {4}, ir, (device-cuda, sm_35) 6: backend, {5}, assembler, (device-cuda, sm_35) 7: assembler, {6}, object, (device-cuda, sm_35) 8: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {7}, object 9: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {6}, assembler 10: input, "cudatests.cu", cuda, (device-cuda, sm_37) 11: preprocessor, {10}, cuda-cpp-output, (device-cuda, sm_37) 12: compiler, {11}, ir, (device-cuda, sm_37) 13: backend, {12}, assembler, (device-cuda, sm_37) 14: assembler, {13}, object, (device-cuda, sm_37) 15: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {14}, object 16: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {13}, assembler 17: linker, {8, 9, 15, 16}, cuda-fatbin, (device-cuda) 18: offload, "host-cuda (powerpc64le-unknown-linux-gnu)" {2}, "device-cuda (nvptx64-nvidia-cuda)" {17}, ir 19: backend, {18}, assembler 20: assembler, {19}, object 21: input, "cuda", object 22: input, "cudart", object 23: linker, {20, 21, 22}, image ``` The changes in this patch pass the existent regression tests (keeps the existent functionality) and resulting binaries execute correctly in a Power8+K40 machine. Reviewers: echristo, hfinkel, jlebar, ABataev, tra Subscribers: guansong, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D18171 llvm-svn: 275645
* [CUDA] Add utility functions for dealing with CUDA versions / architectures.Justin Lebar2016-07-061-13/+16
| | | | | | | | | | | | | | | | | | Summary: Currently our handling of CUDA architectures is scattered all around clang. This patch centralizes it. A key advantage of this centralization is that you can now write a C++ switch on e.g. CudaArch and get a compile error if you don't handle one of the enum values. Reviewers: tra Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D21867 llvm-svn: 274681
* Use ArgList::hasFlag to check if -miamcu/-mno-iamcu is passed. NFC.Andrey Turetskiy2016-06-291-21/+18
| | | | | | Differential Revision: http://reviews.llvm.org/D21641 llvm-svn: 274119
* [X86] Add -mno-iamcu option.Andrey Turetskiy2016-06-201-18/+21
| | | | | | | | | | Add -mno-iamcu option to: 1) Countervail -miamcu option easily 2) Be compatible with GCC which supports this option Differential Revision: http://reviews.llvm.org/D21469 llvm-svn: 273147
* Compilation for Intel MCU (Part 2/3)Andrey Turetskiy2016-06-161-0/+1
| | | | | | | | | | | | This is the second patch required to support compilation for Intel MCU target (e.g. Intel(R) Quark(TM) micro controller D 2000). When IAMCU triple is used: * Recognize and use IAMCU GCC toolchain * Set up include paths * Forbid C++ Differential Revision: http://reviews.llvm.org/D19274 llvm-svn: 272883
* [CUDA][OpenMP] Create generic offload toolchainsSamuel Antao2016-06-131-14/+29
| | | | | | | | | | | | | | | | | | | Summary: This patch introduces the concept of offloading tool chain and offloading kind. Each tool chain may have associated an offloading kind that marks it as used in a given programming model that requires offloading. It also adds the logic to iterate on the tool chains based on the kind. Currently, only CUDA is supported, but in general a programming model (an offloading kind) may have associated multiple tool chains that require supporting offloading. This patch does not add tests - its goal is to keep the existing functionality. This patch is the first of a series of three that attempts to make the current support of CUDA more generic and easier to extend to other programming models, namely OpenMP. It tries to capture the suggestions/improvements/concerns on the initial proposal in http://lists.llvm.org/pipermail/cfe-dev/2016-February/047547.html. It only tackles the more consensual part of the proposal, i.e.does not address the problem of intermediate files bundling yet. Reviewers: ABataev, jlebar, echristo, hfinkel, tra Subscribers: guansong, Hahnfeld, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin Differential Revision: http://reviews.llvm.org/D18170 llvm-svn: 272571
* Revert "Strip Android version when looking up toolchain paths."Chandler Carruth2016-06-111-9/+1
| | | | | | | This reverts commit r272413. The tests here have been failing on several different build bots for over 10 hours. llvm-svn: 272454
OpenPOWER on IntegriCloud