編譯選項相關：

想要添加的選項，以我添加的-fdpu為例子

能通過clang --help得到的選項，整體需要一個解析文件(好像在LLVM項目中都是通過後綴名為xxx.td和xxx.def的文件來進行存儲的，然後通過xxx.h聲明，xxx.cpp真正進行解析)

比如添加-fdpu，是在clang/include/Driver/Options.td添加相應的選項(其實就是憑感覺加，感覺和哪個比較像就對應加一個，具體的內容沒研究明白)，我是加成了這樣：

def fdpu : Flag<["-"], "fdpu">, Flags<[DriverOption, CC1Option]>,

HelpText<"Enable DPU extensions">;

這個裏邊的選項都是直接面向用戶的，因此加的時候可以不是那麽嚴謹，裏邊的Flags是標記作為DriverOption和要傳遞給CC1（CC1真正完成編譯工作，裏邊才是我們需要添加的動作）

但是也不要亂加，這個裏邊其實是有定義Group的，比如ActionGroup中定義的都是動作，其他像M_Group等的，都是各種語言相應的Group。而且這個Group的定義是有相應的動作，比如像源源變換等操作，最好就再建立一個Action相關的選項，留給CC1使用

我的實現是在clang/include/Driver/CC1Options.td中添加了一個要實現源源變化的

def rewrite_dpu : Flag<["-"], "rewrite-dpu">,

HelpText<"Rewrite dpu source to C">;

上邊也說了，這個是一個要驅動進行源源變換的Action，所以被放在了Action_Group組內。

之前也提到了，我們添加的選項希望都是由用戶指定的，在Options和CC1Options中添加了選項還不算完，還需要在clang/include/Driver/Types.def中添加兩種選項，具體用法還不是特別清楚，只知道最後一個”u”告訴編譯器，這是一個用戶指定的選項(user specified)

TYPE("dpu-cpp-output", PP_DPU, INVALID, "dpui", "u")

TYPE("dpu", DPU, PP_DPU, "c", "u")

這裏不是使用的都是TYPE麽，所以後邊就會出現TY_XXX的東西

在clang/lib/Driver/Types.cpp中對Types.def文件進行了解析，這個函數完成的是文件名後綴字符串的解析types::ID types::lookupTypeForExtension(llvm::StringRef Ext)

我們在其中添加dpu的解析：

.Case("dpu", TY_DPU)

.Case("dpui", TY_PP_DPU)

也就是我們這裏假設會出現一種專用於DPU平臺的xxx.dpui的代碼（留作以後使用，目前其實沒啥用）

這裏做了改動以後，需要在clang可以接受的類型中添加對應的處理，其實就是在

bool types::isAcceptedByClang(ID Id)函數中添加

case TY_DPU: case TY_PP_DPU:

有了類型處理以後，真正進入處理過程。

在clang/lib/Driver/Tools.cpp的

void Clang::ConstructJob(Compilation &C, const JobAction &JA,

const InputInfo &Output, const InputInfoList &Inputs,

const ArgList &Args, const char *LinkingOutput) const 中

這個函數內包含著編譯的各個phase的編譯工作，比如

isa<AnalyzeJobAction>(JA)

isa<PrecompileJobAction>(JA)

添加對DPU的支持，是在

(isa<CompileJobAction>(JA) || isa<BackendJobAction>(JA)) && "Invalid action for clang tool.")分支內添加

else if (JA.getType() == types::TY_DPU) {

CmdArgs.push_back("-fdpu");

CmdArgs.push_back("-rewrite-dpu");

}

其實就是在真正的編譯過程中加入-fdpu和-rewrite-dpu兩個選項

這只是在編譯過程中加了選項，還要根據選項添加編譯任務。在clang/lib/Driver/Driver.cpp中添加各個階段真正的任務

比如我是在phases::Compile:階段添加了

if (Args.hasArg(options::OPT_fdpu)) {

return new CompileJobAction(Input, types::TY_DPU);

}

同時為了能在最後一個階段有一定的作用，在

phases::ID Driver::getFinalPhase(const DerivedArgList &DAL, Arg **FinalPhaseArg) const

也添加了相應的處理代碼

// -{fsyntax-only,-analyze,emit-ast} only run up to the compiler. 這個分支下添加

(PhaseArg = DAL.getLastArg(options::OPT_fdpu) ) ||

編譯的階段和編譯的任務都添加好了，之後就是具體的Action實現了。總體來說就是在Frontend中添加響應的Action。

先定義好InputKind，在clang/include/clang/Frontend/FrontendOptions.h的enum InputKind中加入

IK_DPU,

IK_PreprocessedDPU

因為要做個源源變換的工具，在ActionKind中添加響應的項

RewriteDPU, ///< Run DPU

上邊說過了，定義了IK_DPU和IK_PreprocessedDPU這兩個符號，但是，該怎麽解析才能確定是這兩個符號。因此在clang/lib/Frontend/FrontendOptions.cpp中的

InputKind FrontendOptions::getInputKindForExtension(StringRef Extension)中添加

.Case("dpui", IK_PreprocessedDPU)

.Case("dpu", IK_DPU)

意思就是遇到這樣的字符串，就解析成這兩個值

在clang/lib/Frontend/FrontendActions.cpp中的void PrintPreambleAction::ExecuteAction() 中添加IK_DPU和 IK_PreprocessedDPU的支持

case IK_DPU:

break;

case IK_PreprocessedDPU:

前期準備工作基本上差不多了，Action也準備好了，就差真正的調用了。

在clang/lib/Frontend/CompilerInstance.cpp中，存在了大量對CompileInstance的設置和修改，為了能對DPU中的輸入文件進行兼容，在

static InputKind getSourceInputKindFromOptions(const LangOptions &LangOpts)中添加了相應的處理

if (LangOpts.DPU)

return IK_DPU;

CompileInstance修改好，終於到了真正的調用過程CompileInvocation

在clang/lib/Frontend/CompilerInvocation.cpp中

static InputKind ParseFrontendArgs(FrontendOptions &Opts, ArgList &Args,

DiagnosticsEngine &Diags,

bool &IsHeaderFile)函數中

是針對前端進行的處理，前邊提到了我們把前端的處理作為ActionGroup中一個子項rewrite_dpu，那麽這裏的處理代碼就應該加在

if (const Arg *A = Args.getLastArg(OPT_Action_Group)) {

switch (A->getOption().getID())

下邊，具體如下：

case OPT_rewrite_dpu:

Opts.ProgramAction = frontend::RewriteDPU; break;

前邊說過，這個是要進行源源變換的，源源變換的輸出是c或者dpui

因此在該函數下半部分針對字符串進行解析的時候，添加對應的處理，也就是在

DashX = llvm::StringSwitch<InputKind>(A->getValue())

添加

.Case("dpu", IK_DPU)

.Case("dpu-cpp-output", IK_PreprocessedDPU)

這裏同樣可以對語言進行設置，我這裏是針對

void CompilerInvocation::setLangDefaults(LangOptions &Opts, InputKind IK,

const llvm::Triple &T,

PreprocessorOptions &PPOpts,

LangStandard::Kind LangStd)函數

if (LangStd == LangStandard::lang_unspecified)分之下進行了支持

case IK_DPU:

case IK_PreprocessedDPU:

LangStd = LangStandard::lang_gnu11; //C++ 11的支持

break;

等等，這裏只有一個類型的聲明，具體的調用我們還沒有看到，我們希望看到的是具體的new classA類似的調用過程。因此，在具體的clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp中的

static std::unique_ptr<FrontendAction> CreateFrontendBaseAction(CompilerInstance &CI)函數內存著真正的調用過程，添加處理如下：

case RewriteDPU: return llvm::make_unique<RewriteDPUAction>();

RewriteDPUAction這個類是我們真正實現的類。

這個類需要繼承至public ASTFrontendAction

實現特別簡單

std::unique_ptr<ASTConsumer> RewriteDPUAction::CreateASTConsumer(CompilerInstance &CI,

StringRef InFile) {

if (std::unique_ptr<raw_ostream> OS = CI.createDefaultOutputFile(false, InFile)) {

return CreateDPUConsumer(CI, InFile ,std::move(OS));

}

return nullptr;

}

bool RewriteDPUAction::BeginInvocation(CompilerInstance &CI) {

return true;

}

剩下所有的東西都交給DPUConsumer這個消費者來處理

我在DPUConsumer中添加了對public SemaConsumer, public PassManager的繼承，以此對Pass管理器和語法消費者的支持，從而準備支持制導。

在這個層次，就可以隨心所欲的添加自己想要的Pass了

目前還在開發中，代碼不方便open，之後應該會作為一個開源項目在GitHub上見到，有什麽問題可以給我發消息。最近也比較忙，沒時間修改格式，待假期有空修改。

http://www.cnblogs.com/jourluohua

Clang編譯選項和Pass構建