Clang编译选项和Pass构建
编译选项相关：
想要添加的选项，以我添加的-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中添加了一个要实现源源变化的Action：
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
