Commit Graph

11 Commits

Author SHA1 Message Date
Justin Lebar 066494d8c1 [CUDA] Print an error if you try to compile with < sm_30 on CUDA 9.
Summary:
CUDA 9's minimum sm is sm_30.

Ideally we should also make sm_30 the default when compiling with CUDA
9, but that seems harder than it should be.

Subscribers: sanjoy

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

llvm-svn: 316611
2017-10-25 21:32:06 +00:00
Jonas Hahnfeld 30b4418e5a [CMake][OpenMP] Customize default offloading arch
For the shuffle instructions in reductions we need at least sm_30
but the user may want to customize the default architecture.

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

llvm-svn: 315996
2017-10-17 13:37:36 +00:00
Gheorghe-Teodor Bercea 9c52574886 [OpenMP] Enable previously successful offloading tests.
Create a separate test file to contain all tests for OpenMP
offloading to GPUs.

Make libdevice checking more robust by accounting for
the case in which no libdevice is found.

This changes are in connrection with diff: D29660

llvm-svn: 310718
2017-08-11 15:46:22 +00:00
Gheorghe-Teodor Bercea 14528c60ba [OpenMP] Delete tests in openmp-offload.c which cuase failures
until a better way to perform these tests is figured out.

Change connected to diff: D29654

llvm-svn: 310625
2017-08-10 16:56:59 +00:00
Alex Lorenz 994f231792 Revert r310489 and follow-up commits r310505, r310519, r310537 and r310549
Commit r310489 caused 'openmp-offload.c' test failures on Darwin and other
platforms:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/39230/testReport/junit/Clang/Driver/openmp_offload_c/

The follow-up commits tried to fix the test, but the test is still failing.

llvm-svn: 310580
2017-08-10 10:34:46 +00:00
Gheorghe-Teodor Bercea a659943306 [OpenMP] Provide a default GPU arch that is supported by
the underlying hardware.

This fixes a bug triggered by diff: D29660

llvm-svn: 310549
2017-08-10 05:01:42 +00:00
Gheorghe-Teodor Bercea 2c92693280 [OpenMP] OpenMP device offloading code generation produces a cubin file which is then integrated in the host binary using the host linker.
Diff: D29654

llvm-svn: 310362
2017-08-08 14:33:05 +00:00
Alex Lorenz 7e9c478cda Revert r310291, r310300 and r310332 because of test failure on Darwin
The commit r310291 introduced the failure. r310332 was a test fix commit and
r310300 was a followup commit. I reverted these two to avoid merge conflicts
when reverting.

The 'openmp-offload.c' test is failing on Darwin because the following
run lines:
// RUN:   touch %t1.o
// RUN:   touch %t2.o
// RUN:   %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda -save-temps -no-canonical-prefixes %t1.o %t2.o 2>&1 \
// RUN:   | FileCheck -check-prefix=CHK-TWOCUBIN %s

trigger the following assertion:

Driver.cpp:3418:
    assert(CachedResults.find(ActionTC) != CachedResults.end() &&
           "Result does not exist??");

llvm-svn: 310345
2017-08-08 11:20:17 +00:00
Gheorghe-Teodor Bercea 4cdba82ee0 [OpenMP] Integrate OpenMP target region cubin into host binary
Summary: OpenMP device offloading code generation produces a cubin file which is then integrated in the host binary using the host linker.

Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, Hahnfeld, jlebar, rnk, hfinkel, tstellar

Reviewed By: hfinkel

Subscribers: sfantao, rnk, rengolin, cfe-commits

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

llvm-svn: 310291
2017-08-07 20:01:48 +00:00
Gheorghe-Teodor Bercea f0f29608d0 [OpenMP] Extend CLANG target options with device offloading kind.
Summary: Pass the type of the device offloading when building the tool chain for a particular target architecture. This is required when supporting multiple tool chains that target a single device type. In our particular use case, the OpenMP and CUDA tool chains will use the same ```addClangTargetOptions ``` method. This enables the reuse of common options and ensures control over options only supported by a particular tool chain.

Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, jlebar, hfinkel, tstellar, Hahnfeld

Reviewed By: hfinkel

Subscribers: jgravelle-google, aheejin, rengolin, jfb, dschuff, sbc100, cfe-commits

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

llvm-svn: 307272
2017-07-06 16:22:21 +00:00
David L. Jones f561abab56 [Driver] Consolidate tools and toolchains by target platform. (NFC)
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)

This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.

There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.

I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.

There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.

Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar

Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits

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

llvm-svn: 297250
2017-03-08 01:02:16 +00:00