[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 09:02:16 +08:00
|
|
|
//===--- Cuda.h - Cuda ToolChain Implementations ----------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_CUDA_H
|
|
|
|
#define LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_CUDA_H
|
|
|
|
|
|
|
|
#include "clang/Basic/Cuda.h"
|
|
|
|
#include "clang/Basic/VersionTuple.h"
|
|
|
|
#include "clang/Driver/Action.h"
|
|
|
|
#include "clang/Driver/Multilib.h"
|
|
|
|
#include "clang/Driver/ToolChain.h"
|
|
|
|
#include "clang/Driver/Tool.h"
|
|
|
|
#include "llvm/ADT/Optional.h"
|
|
|
|
#include "llvm/ADT/SmallSet.h"
|
|
|
|
#include "llvm/Support/Compiler.h"
|
|
|
|
#include <set>
|
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
namespace clang {
|
|
|
|
namespace driver {
|
|
|
|
|
|
|
|
/// A class to find a viable CUDA installation
|
|
|
|
class CudaInstallationDetector {
|
|
|
|
private:
|
|
|
|
const Driver &D;
|
|
|
|
bool IsValid = false;
|
|
|
|
CudaVersion Version = CudaVersion::UNKNOWN;
|
|
|
|
std::string InstallPath;
|
|
|
|
std::string BinPath;
|
|
|
|
std::string LibPath;
|
|
|
|
std::string LibDevicePath;
|
|
|
|
std::string IncludePath;
|
|
|
|
llvm::StringMap<std::string> LibDeviceMap;
|
|
|
|
|
|
|
|
// CUDA architectures for which we have raised an error in
|
|
|
|
// CheckCudaVersionSupportsArch.
|
2017-10-26 05:32:06 +08:00
|
|
|
mutable llvm::SmallSet<CudaArch, 4> ArchsWithBadVersion;
|
[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 09:02:16 +08:00
|
|
|
|
|
|
|
public:
|
|
|
|
CudaInstallationDetector(const Driver &D, const llvm::Triple &HostTriple,
|
|
|
|
const llvm::opt::ArgList &Args);
|
|
|
|
|
|
|
|
void AddCudaIncludeArgs(const llvm::opt::ArgList &DriverArgs,
|
|
|
|
llvm::opt::ArgStringList &CC1Args) const;
|
|
|
|
|
|
|
|
/// \brief Emit an error if Version does not support the given Arch.
|
|
|
|
///
|
|
|
|
/// If either Version or Arch is unknown, does not emit an error. Emits at
|
|
|
|
/// most one error per Arch.
|
|
|
|
void CheckCudaVersionSupportsArch(CudaArch Arch) const;
|
|
|
|
|
|
|
|
/// \brief Check whether we detected a valid Cuda install.
|
|
|
|
bool isValid() const { return IsValid; }
|
|
|
|
/// \brief Print information about the detected CUDA installation.
|
|
|
|
void print(raw_ostream &OS) const;
|
|
|
|
|
|
|
|
/// \brief Get the detected Cuda install's version.
|
|
|
|
CudaVersion version() const { return Version; }
|
|
|
|
/// \brief Get the detected Cuda installation path.
|
|
|
|
StringRef getInstallPath() const { return InstallPath; }
|
|
|
|
/// \brief Get the detected path to Cuda's bin directory.
|
|
|
|
StringRef getBinPath() const { return BinPath; }
|
|
|
|
/// \brief Get the detected Cuda Include path.
|
|
|
|
StringRef getIncludePath() const { return IncludePath; }
|
|
|
|
/// \brief Get the detected Cuda library path.
|
|
|
|
StringRef getLibPath() const { return LibPath; }
|
|
|
|
/// \brief Get the detected Cuda device library path.
|
|
|
|
StringRef getLibDevicePath() const { return LibDevicePath; }
|
|
|
|
/// \brief Get libdevice file for given architecture
|
|
|
|
std::string getLibDeviceFile(StringRef Gpu) const {
|
|
|
|
return LibDeviceMap.lookup(Gpu);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
namespace tools {
|
|
|
|
namespace NVPTX {
|
|
|
|
|
|
|
|
// Run ptxas, the NVPTX assembler.
|
|
|
|
class LLVM_LIBRARY_VISIBILITY Assembler : public Tool {
|
|
|
|
public:
|
|
|
|
Assembler(const ToolChain &TC)
|
|
|
|
: Tool("NVPTX::Assembler", "ptxas", TC, RF_Full, llvm::sys::WEM_UTF8,
|
|
|
|
"--options-file") {}
|
|
|
|
|
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
|
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
|
|
|
};
|
|
|
|
|
|
|
|
// Runs fatbinary, which combines GPU object files ("cubin" files) and/or PTX
|
|
|
|
// assembly into a single output file.
|
|
|
|
class LLVM_LIBRARY_VISIBILITY Linker : public Tool {
|
|
|
|
public:
|
|
|
|
Linker(const ToolChain &TC)
|
|
|
|
: Tool("NVPTX::Linker", "fatbinary", TC, RF_Full, llvm::sys::WEM_UTF8,
|
|
|
|
"--options-file") {}
|
|
|
|
|
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
|
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
|
|
|
};
|
|
|
|
|
2017-08-08 22:33:05 +08:00
|
|
|
class LLVM_LIBRARY_VISIBILITY OpenMPLinker : public Tool {
|
|
|
|
public:
|
|
|
|
OpenMPLinker(const ToolChain &TC)
|
|
|
|
: Tool("NVPTX::OpenMPLinker", "fatbinary", TC, RF_Full, llvm::sys::WEM_UTF8,
|
|
|
|
"--options-file") {}
|
|
|
|
|
|
|
|
bool hasIntegratedCPP() const override { return false; }
|
|
|
|
|
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
|
|
|
};
|
|
|
|
|
[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 09:02:16 +08:00
|
|
|
} // end namespace NVPTX
|
|
|
|
} // end namespace tools
|
|
|
|
|
|
|
|
namespace toolchains {
|
|
|
|
|
|
|
|
class LLVM_LIBRARY_VISIBILITY CudaToolChain : public ToolChain {
|
|
|
|
public:
|
|
|
|
CudaToolChain(const Driver &D, const llvm::Triple &Triple,
|
2017-08-08 22:33:05 +08:00
|
|
|
const ToolChain &HostTC, const llvm::opt::ArgList &Args,
|
|
|
|
const Action::OffloadKind OK);
|
[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 09:02:16 +08:00
|
|
|
|
|
|
|
virtual const llvm::Triple *getAuxTriple() const override {
|
|
|
|
return &HostTC.getTriple();
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::opt::DerivedArgList *
|
|
|
|
TranslateArgs(const llvm::opt::DerivedArgList &Args, StringRef BoundArch,
|
|
|
|
Action::OffloadKind DeviceOffloadKind) const override;
|
|
|
|
void addClangTargetOptions(const llvm::opt::ArgList &DriverArgs,
|
[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-07 00:22:21 +08:00
|
|
|
llvm::opt::ArgStringList &CC1Args,
|
|
|
|
Action::OffloadKind DeviceOffloadKind) const override;
|
[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 09:02:16 +08:00
|
|
|
|
|
|
|
// Never try to use the integrated assembler with CUDA; always fork out to
|
|
|
|
// ptxas.
|
|
|
|
bool useIntegratedAs() const override { return false; }
|
|
|
|
bool isCrossCompiling() const override { return true; }
|
|
|
|
bool isPICDefault() const override { return false; }
|
|
|
|
bool isPIEDefault() const override { return false; }
|
|
|
|
bool isPICDefaultForced() const override { return false; }
|
|
|
|
bool SupportsProfiling() const override { return false; }
|
|
|
|
bool SupportsObjCGC() const override { return false; }
|
|
|
|
|
|
|
|
void AddCudaIncludeArgs(const llvm::opt::ArgList &DriverArgs,
|
|
|
|
llvm::opt::ArgStringList &CC1Args) const override;
|
|
|
|
|
|
|
|
void addClangWarningOptions(llvm::opt::ArgStringList &CC1Args) const override;
|
|
|
|
CXXStdlibType GetCXXStdlibType(const llvm::opt::ArgList &Args) const override;
|
|
|
|
void
|
|
|
|
AddClangSystemIncludeArgs(const llvm::opt::ArgList &DriverArgs,
|
|
|
|
llvm::opt::ArgStringList &CC1Args) const override;
|
|
|
|
void AddClangCXXStdlibIncludeArgs(
|
|
|
|
const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CC1Args) const override;
|
|
|
|
void AddIAMCUIncludeArgs(const llvm::opt::ArgList &DriverArgs,
|
|
|
|
llvm::opt::ArgStringList &CC1Args) const override;
|
|
|
|
|
|
|
|
SanitizerMask getSupportedSanitizers() const override;
|
|
|
|
|
|
|
|
VersionTuple
|
|
|
|
computeMSVCVersion(const Driver *D,
|
|
|
|
const llvm::opt::ArgList &Args) const override;
|
|
|
|
|
|
|
|
const ToolChain &HostTC;
|
|
|
|
CudaInstallationDetector CudaInstallation;
|
|
|
|
|
|
|
|
protected:
|
|
|
|
Tool *buildAssembler() const override; // ptxas
|
|
|
|
Tool *buildLinker() const override; // fatbinary (ok, not really a linker)
|
2017-08-08 22:33:05 +08:00
|
|
|
|
|
|
|
private:
|
|
|
|
const Action::OffloadKind OK;
|
[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 09:02:16 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
} // end namespace toolchains
|
|
|
|
} // end namespace driver
|
|
|
|
} // end namespace clang
|
|
|
|
|
|
|
|
#endif // LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_CUDA_H
|