[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
|
|
|
//===--- Clang.h - Clang Tool and ToolChain Implementations ====-*- C++ -*-===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
[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
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_Clang_H
|
|
|
|
#define LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_Clang_H
|
|
|
|
|
|
|
|
#include "MSVC.h"
|
|
|
|
#include "clang/Basic/DebugInfoOptions.h"
|
|
|
|
#include "clang/Driver/Driver.h"
|
|
|
|
#include "clang/Driver/Tool.h"
|
|
|
|
#include "clang/Driver/Types.h"
|
|
|
|
#include "llvm/ADT/Triple.h"
|
|
|
|
#include "llvm/Option/Option.h"
|
|
|
|
#include "llvm/Support/raw_ostream.h"
|
|
|
|
|
|
|
|
namespace clang {
|
|
|
|
class ObjCRuntime;
|
|
|
|
namespace driver {
|
|
|
|
|
|
|
|
namespace tools {
|
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// Clang compiler tool.
|
[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
|
|
|
class LLVM_LIBRARY_VISIBILITY Clang : public Tool {
|
|
|
|
public:
|
|
|
|
static const char *getBaseInputName(const llvm::opt::ArgList &Args,
|
|
|
|
const InputInfo &Input);
|
|
|
|
static const char *getBaseInputStem(const llvm::opt::ArgList &Args,
|
|
|
|
const InputInfoList &Inputs);
|
|
|
|
static const char *getDependencyFileName(const llvm::opt::ArgList &Args,
|
|
|
|
const InputInfoList &Inputs);
|
|
|
|
|
|
|
|
private:
|
|
|
|
void AddPreprocessingOptions(Compilation &C, const JobAction &JA,
|
|
|
|
const Driver &D, const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs,
|
|
|
|
const InputInfo &Output,
|
|
|
|
const InputInfoList &Inputs) const;
|
|
|
|
|
2017-09-03 12:47:00 +08:00
|
|
|
void RenderTargetOptions(const llvm::Triple &EffectiveTriple,
|
|
|
|
const llvm::opt::ArgList &Args, bool KernelOrKext,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
|
[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
|
|
|
void AddAArch64TargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
void AddARMTargetArgs(const llvm::Triple &Triple,
|
|
|
|
const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs,
|
|
|
|
bool KernelOrKext) const;
|
|
|
|
void AddARM64TargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
void AddMIPSTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
void AddPPCTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
void AddR600TargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
2018-01-11 21:36:56 +08:00
|
|
|
void AddRISCVTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
[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
|
|
|
void AddSparcTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
void AddSystemZTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
void AddX86TargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
void AddHexagonTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
void AddLanaiTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
void AddWebAssemblyTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
|
|
|
|
enum RewriteKind { RK_None, RK_Fragile, RK_NonFragile };
|
|
|
|
|
|
|
|
ObjCRuntime AddObjCRuntimeArgs(const llvm::opt::ArgList &args,
|
|
|
|
llvm::opt::ArgStringList &cmdArgs,
|
|
|
|
RewriteKind rewrite) const;
|
|
|
|
|
|
|
|
void AddClangCLArgs(const llvm::opt::ArgList &Args, types::ID InputType,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs,
|
|
|
|
codegenoptions::DebugInfoKind *DebugInfoKind,
|
|
|
|
bool *EmitCodeView) const;
|
|
|
|
|
|
|
|
visualstudio::Compiler *getCLFallback() const;
|
|
|
|
|
|
|
|
mutable std::unique_ptr<visualstudio::Compiler> CLFallback;
|
|
|
|
|
|
|
|
mutable std::unique_ptr<llvm::raw_fd_ostream> CompilationDatabase = nullptr;
|
|
|
|
void DumpCompilationDatabase(Compilation &C, StringRef Filename,
|
|
|
|
StringRef Target,
|
|
|
|
const InputInfo &Output, const InputInfo &Input,
|
|
|
|
const llvm::opt::ArgList &Args) const;
|
|
|
|
|
|
|
|
public:
|
|
|
|
Clang(const ToolChain &TC);
|
|
|
|
~Clang() override;
|
|
|
|
|
|
|
|
bool hasGoodDiagnostics() const override { return true; }
|
|
|
|
bool hasIntegratedAssembler() const override { return true; }
|
|
|
|
bool hasIntegratedCPP() const override { return true; }
|
|
|
|
bool canEmitIR() const override { return true; }
|
|
|
|
|
|
|
|
void ConstructJob(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfo &Output, const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
|
|
|
};
|
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// Clang integrated assembler tool.
|
[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
|
|
|
class LLVM_LIBRARY_VISIBILITY ClangAs : public Tool {
|
|
|
|
public:
|
|
|
|
ClangAs(const ToolChain &TC)
|
|
|
|
: Tool("clang::as", "clang integrated assembler", TC, RF_Full) {}
|
|
|
|
void AddMIPSTargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
void AddX86TargetArgs(const llvm::opt::ArgList &Args,
|
|
|
|
llvm::opt::ArgStringList &CmdArgs) const;
|
|
|
|
bool hasGoodDiagnostics() const override { return true; }
|
|
|
|
bool hasIntegratedAssembler() const override { return false; }
|
|
|
|
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;
|
|
|
|
};
|
|
|
|
|
|
|
|
/// Offload bundler tool.
|
|
|
|
class LLVM_LIBRARY_VISIBILITY OffloadBundler final : public Tool {
|
|
|
|
public:
|
|
|
|
OffloadBundler(const ToolChain &TC)
|
|
|
|
: Tool("offload bundler", "clang-offload-bundler", TC) {}
|
|
|
|
|
|
|
|
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;
|
|
|
|
void ConstructJobMultipleOutputs(Compilation &C, const JobAction &JA,
|
|
|
|
const InputInfoList &Outputs,
|
|
|
|
const InputInfoList &Inputs,
|
|
|
|
const llvm::opt::ArgList &TCArgs,
|
|
|
|
const char *LinkingOutput) const override;
|
|
|
|
};
|
|
|
|
} // end namespace tools
|
|
|
|
|
|
|
|
} // end namespace driver
|
|
|
|
} // end namespace clang
|
|
|
|
|
|
|
|
#endif // LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_CLANG_H
|