企业官网建设流程全解析

简介：本资源是中国科学技术大学2020年秋季《编译原理》课程高分实践项目成果，面向计算机专业本科生、编译技术初学者及系统编程爱好者，完整呈现一个具备工业级模块划分的C-MinusF编译器实现。项目覆盖词法分析、语法分析、LLVM IR生成及循环不变式外提、常量传播、活跃变量分析等核心优化功能，兼具教学深度与工程实践价值。压缩包共245个文件，含62个.cminus测试用例、27个.cpp源码、19个.md文档（含设计说明与实验报告）、12个.ll中间代码、10个.tokens词法输出及syntax_tree等结构化中间产物，总大小3.69MB，目录组织清晰，便于按编译流程分阶段研读调试。已有85人学习下载，读者可直接复现从源码到优化IR的全流程，获取完整可运行代码、多组测试用例、语法树可视化输出及各阶段调试日志，是深入理解编译器构造与优化机制的优质实操范本。

1. 这不是作业提交包，而是一套能跑通完整编译流水线的C-MinusF工业级教学编译器

如果你正在啃《编译原理》（清华大学出版社第三版）第二章词法分析、第四章语法分析、第九章中间代码生成、第十章优化——尤其是循环不变式外提（Loop-Invariant Code Motion）、常量传播（Constant Propagation）、活跃变量分析（Live Variable Analysis）这些被学生称为“玄学三连”的硬核章节，那么这个来自中国科学技术大学2020年秋季学期的满分实践项目，就是你手头最接近真实工业编译器脉搏的教学实现。它不是用Java写个玩具Parser再print AST就交差的实验，而是从.cminusf源码出发，经词法分析→语法分析→语义检查→LLVM IR生成→IR级优化→LLVM后端编译成可执行文件的全链路闭环。关键在于：所有优化均在LLVM IR上完成，而非抽象语法树或三地址码；所有算法均严格对应龙书（Dragon Book）第9、10章理论，但落地时绕开了教科书里没写的“黑匣子”——比如如何把活跃变量分析结果映射到LLVM的Value与Instruction生命周期、如何在LLVM Pass中安全插入/删除指令而不破坏SSA形式、为什么循环不变式外提必须配合支配边界（Dominance Frontier）计算。它适合两类人：一是山科大、燕山大学等高校编译原理课程设计卡在IR优化环节的同学，二是想跳过ANTLR自动生成、亲手打磨控制流图（CFG）构建与数据流分析框架的进阶学习者。这不是答案抄写器，是能让你debug到凌晨三点、却在看到opt -O2输出和自己Pass输出完全一致时拍桌大笑的血泪工程。

2. 从C-MinusF源码到LLVM IR：四阶段编译器骨架搭建与词法/语法分析实现

2.1 C-MinusF语言规范与词法分析器手写逻辑（非Lex/Yacc）

C-MinusF是C-Minus的扩展子集，核心差异在于：支持for循环（含初始化、条件、增量三部分）、函数参数传值、局部变量作用域、以及int一维数组（如int a[10]）。词法分析器采用纯C++手写状态机，不依赖Flex或ANTLR——这是中科大该课程明确要求的“理解底层机制”训练点。其Token定义严格对齐LLVM的llvm::StringRef与llvm::SMLoc定位需求：

// Token.h 关键枚举（截取） enum TokenType { TOK_EOF, TOK_IDENTIFIER, // 变量名、函数名 TOK_NUMBER, // 整数字面量 TOK_STRING, // 字符串字面量（仅用于printf） TOK_FOR, TOK_WHILE, TOK_IF, TOK_ELSE, TOK_RETURN, TOK_INT, TOK_VOID, TOK_PLUS, TOK_MINUS, TOK_STAR, TOK_SLASH, TOK_PERCENT, TOK_EQ, TOK_NEQ, TOK_LT, TOK_LE, TOK_GT, TOK_GE, TOK_ASSIGN, // '=' TOK_SEMI, TOK_COMMA, TOK_LPAREN, TOK_RPAREN, TOK_LBRACE, TOK_RBRACE, TOK_LBRACKET, TOK_RBRACKET, TOK_ARROW // "->" 用于结构体访问（C-MinusF暂未启用，预留） };

提示：词法分析器输出的每个Token必须携带llvm::SMLoc（源码位置），这是后续错误报告和LLVM调试信息（Debug Info）生成的基础。中科大评分细则中，缺失位置信息直接扣15%。

词法分析主循环采用双缓冲区设计，避免频繁内存分配：

// Lexer.cpp 核心扫描逻辑（简化） bool Lexer::advance() { curPos = nextPos; if (curPos >= buf.size()) return false; char c = buf[curPos]; nextPos = curPos + 1; switch (c) { case ' ': case '\t': case '\n': case '\r': skipWhitespace(); // 跳过空白，不生成Token return advance(); // 递归调用，直到非空白 case '0'...'9': return lexNumber(); case 'a'...'z': case 'A'...'Z': case '_': return lexIdentifier(); case '+': case '-': case '*': case '/': case '%': return lexOperator(); // ... 其他case } return false; }

lexNumber()需处理十进制整数（无小数点、无科学计数法），lexIdentifier()需区分关键字（如for,int）与标识符，此处用std::unordered_set<std::string>预存32个关键字，O(1)查表。关键细节：C-MinusF允许下划线开头的标识符（如_temp），但关键字禁止以下划线开头——词法分析器必须拒绝_for这类非法token，否则语法分析阶段会因TOK_IDENTIFIER与TOK_FOR冲突而崩溃。

2.2 基于递归下降的语法分析器与AST构建

语法分析采用手工递归下降（Recursive Descent），不使用Yacc/Bison。选择此方案的核心原因是：LLVM IR生成需要精确控制AST节点的内存布局与生命周期，而自动生成工具产生的AST往往嵌套过深、指针关系混乱，不利于后续遍历优化。C-MinusF的BNF文法被拆解为以下核心函数：

ForStmtNode是循环优化的基石，其字段设计直指后续优化需求：

struct ForStmtNode : StmtNode { ExprNode* init; // for(init; cond; incr) → 初始化表达式 ExprNode* cond; // 条件表达式 ExprNode* incr; // 增量表达式 StmtNode* body; // 循环体 llvm::BasicBlock* loopHeader; // LLVM CFG中循环头块（后期填充） llvm::BasicBlock* loopLatch; // LLVM CFG中循环尾块（后期填充） std::vector<llvm::Value*> loopInvariantExprs; // 外提后的不变式（后期填充） };

注意：loopHeader与loopLatch字段在语法分析阶段为空，仅作占位。它们将在LLVM IR生成阶段由CFGBuilder根据控制流自动创建并赋值。这种“延迟绑定”设计避免了语法分析器与LLVM API的强耦合，符合课程模块化评分要求。

parseExpr()采用优先级解析（Pratt Parsing）处理运算符优先级，比传统递归下降更简洁。例如a + b * c的AST结构为：

BinaryOp('+') / \ VarRef('a') BinaryOp('*') / \ VarRef('b') VarRef('c')

而非(a + b) * c——这保证了算术表达式语义正确性，是后续常量传播的前提。

2.3 语义分析：符号表管理与类型检查的双重校验

语义分析分两层：第一层是作用域感知的符号表（SymbolTable）构建，第二层是类型兼容性检查。C-MinusF仅支持int和void类型，但数组、函数参数、返回值类型需严格匹配。

符号表采用栈式结构，每进入一个{}块就pushScope()，退出时popScope()：

class SymbolTable { std::stack<std::unordered_map<std::string, SymbolEntry>> scopes; public: void pushScope() { scopes.push({}); } void popScope() { scopes.pop(); } bool insert(const std::string& name, const SymbolEntry& entry) { if (scopes.empty()) return false; auto& top = scopes.top(); if (top.find(name) != top.end()) return false; // 重复声明 top[name] = entry; return true; } SymbolEntry* lookup(const std::string& name) { for (auto it = scopes.rbegin(); it != scopes.rend(); ++it) { auto found = it->find(name); if (found != it->end()) return &found->second; } return nullptr; } };

SymbolEntry包含类型、是否为数组、维度大小、是否为函数等元数据：

struct SymbolEntry { enum Kind { VAR, ARRAY, FUNCTION }; Kind kind; llvm::Type* llvmType; // int32, int32*, void(), etc. size_t arraySize; // 若kind==ARRAY，此值>0 std::vector<llvm::Type*> paramTypes; // 若kind==FUNCTION llvm::Type* returnType; // 若kind==FUNCTION };

类型检查在AST遍历中完成。例如BinaryOpNode检查左右操作数类型是否均为int，ArraySubscriptNode检查基址是否为int*且索引为int。关键陷阱：C-MinusF规定int a[10]声明后，a本身是int*类型（而非int[10]），因此a[5]合法，但a+1也合法——这直接影响LLVM IR中getelementptr指令的生成方式。若类型检查忽略此规则，生成的GEP指令将偏移错误字节数，导致运行时内存越界。

3. LLVM IR生成：从AST到模块的精准映射与控制流图构建

3.1 LLVM环境初始化与模块/函数创建

项目使用LLVM 10.0（中科大2020年教学环境标配），需链接LLVMCore,LLVMSupport,LLVMCodeGen等库。IR生成入口为CodeGenerator::generateIR(ProgramNode* root)：

// CodeGenerator.h class CodeGenerator { llvm::LLVMContext context; std::unique_ptr<llvm::Module> module; llvm::IRBuilder<> builder; std::unordered_map<std::string, llvm::Function*> functionMap; std::stack<llvm::BasicBlock*> breakStack; // 支持break语句 std::stack<llvm::BasicBlock*> continueStack; // 支持continue语句 public: CodeGenerator(const std::string& moduleName) : module(std::make_unique<llvm::Module>(moduleName, context)), builder(context) {} void generateIR(ProgramNode* root); private: void visitFunctionDecl(FunctionDeclNode* node); void visitForStmt(ForStmtNode* node); // ... 其他visit方法 };

module的DataLayout必须显式设置，否则LLVM后端无法确定int大小：

// 在generateIR()开头 module->setDataLayout("e-m:e-p270:32:256-p271:32:256-p272:64:256-i64:64-f80:128-n8:16:32:64-S128"); module->setTargetTriple("x86_64-pc-linux-gnu");

builder的插入点（InsertPoint）在每个函数入口处重置：

void CodeGenerator::visitFunctionDecl(FunctionDeclNode* node) { auto funcType = llvm::FunctionType::get( node->returnType->llvmType, node->paramTypes, false // 不可变参数列表 ); auto func = llvm::Function::Create( funcType, llvm::Function::ExternalLinkage, node->name, module.get() ); functionMap[node->name] = func; // 创建入口基本块 auto entryBB = llvm::BasicBlock::Create(context, "entry", func); builder.SetInsertPoint(entryBB); // 分配函数参数对应的alloca int i = 0; for (auto& arg : func->args()) { auto alloca = builder.CreateAlloca(arg.getType(), nullptr, node->paramNames[i]); builder.CreateStore(&arg, alloca); // ... 记录到符号表 i++; } // 生成函数体 visitStmt(node->body); }

3.2 For循环的LLVM IR生成：头块、条件块、循环体块、增量块的四段式构造

C-MinusF的for (init; cond; incr) body被翻译为标准LLVM CFG结构：

[init] ↓ [header] ←───────┐ ↓ (cond) │ [cond-block] │ ↓ (true) │ [body] │ ↓ │ [incr] │ ↓───────────┘

visitForStmt()实现如下：

void CodeGenerator::visitForStmt(ForStmtNode* node) { // 1. 创建四个基本块 auto headerBB = llvm::BasicBlock::Create(context, "for.header", builder.GetInsertBlock()->getParent()); auto condBB = llvm::BasicBlock::Create(context, "for.cond", builder.GetInsertBlock()->getParent()); auto bodyBB = llvm::BasicBlock::Create(context, "for.body", builder.GetInsertBlock()->getParent()); auto incrBB = llvm::BasicBlock::Create(context, "for.incr", builder.GetInsertBlock()->getParent()); // 2. 当前块跳转到header builder.CreateBr(headerBB); // 3. 设置header块插入点，生成init表达式 builder.SetInsertPoint(headerBB); if (node->init) visitExpr(node->init); // 可能是赋值或声明 // 4. header跳转到cond块 builder.CreateBr(condBB); // 5. 设置cond块插入点，生成条件判断 builder.SetInsertPoint(condBB); auto condVal = visitExpr(node->cond); auto condBool = builder.CreateICmpNE(condVal, llvm::ConstantInt::get(llvm::Type::getInt32Ty(context), 0)); builder.CreateCondBr(condBool, bodyBB, /* exitBB */ builder.GetInsertBlock()->getParent()->getTerminator()->getSuccessor(0)); // 6. 设置body块插入点，生成循环体 builder.SetInsertPoint(bodyBB); visitStmt(node->body); builder.CreateBr(incrBB); // 7. 设置incr块插入点，生成增量表达式 builder.SetInsertPoint(incrBB); if (node->incr) visitExpr(node->incr); builder.CreateBr(condBB); // 跳回cond块 // 8. 记录ForStmtNode的LLVM块引用，供后续优化使用 node->loopHeader = headerBB; node->loopLatch = incrBB; }

关键细节：exitBB（循环出口）不能硬编码为getTerminator()->getSuccessor(0)，而应由visitForStmt()调用者（通常是父StmtNode）提供。项目中通过breakStack/continueStack栈管理跳转目标，确保break语句能准确跳转到循环外第一个块。

3.3 数组访问与函数调用的IR生成：GEP与CallInst的精确控制

ArraySubscriptNode生成getelementptr指令时，必须区分int a[10]（栈分配）与int* p（堆分配）：

void CodeGenerator::visitArraySubscript(ArraySubscriptNode* node) { auto base = visitExpr(node->base); // base可能是AllocaInst或LoadInst auto index = visitExpr(node->index); // 获取base的pointee类型（即int*的pointee是int） auto baseType = base->getType()->getPointerElementType(); auto int32Ty = llvm::Type::getInt32Ty(context); // GEP: ptr, 0, index → 计算a[index]地址 auto gep = builder.CreateGEP( baseType, base, {llvm::ConstantInt::get(int32Ty, 0), index}, "arrayidx" ); // Load该地址的值 auto load = builder.CreateLoad(baseType, gep, "arrayload"); return load; }

函数调用CallExprNode需处理参数传递与返回值接收：

void CodeGenerator::visitCallExpr(CallExprNode* node) { auto calleeFunc = functionMap[node->calleeName]; std::vector<llvm::Value*> args; for (auto& arg : node->args) { args.push_back(visitExpr(arg)); } auto call = builder.CreateCall(calleeFunc, args, "calltmp"); if (calleeFunc->getReturnType() != llvm::Type::getVoidTy(context)) { return call; // 返回值供上层使用 } return nullptr; }

血泪经验：若calleeFunc未在functionMap中注册（如未声明就调用），CreateCall会触发LLVM断言失败。项目中在parseProgram()末尾添加全局函数声明验证，确保所有CallExprNode的calleeName已在functionMap中存在。

4. IR级优化实现：循环不变式外提、常量传播与活跃变量分析的LLVM Pass编写

4.1 循环不变式外提（LICM）：基于支配边界与循环信息的Pass编写

LICM Pass继承自llvm::FunctionPass，核心逻辑在runOnFunction()中：

// LICMPass.h struct LICMPass : public llvm::FunctionPass { static char ID; LICMPass() : FunctionPass(ID) {} bool runOnFunction(llvm::Function& F) override; private: void processLoop(llvm::Loop* L, llvm::LoopInfo& LI, llvm::DominatorTree& DT); bool isLoopInvariant(llvm::Instruction* I, llvm::Loop* L, llvm::LoopInfo& LI); };

processLoop()遍历循环内每条指令，判断其是否为循环不变式：

void LICMPass::processLoop(llvm::Loop* L, llvm::LoopInfo& LI, llvm::DominatorTree& DT) { auto header = L->getHeader(); for (auto BB : L->getBlocks()) { for (auto& I : *BB) { if (isLoopInvariant(&I, L, LI)) { // 检查I是否被header支配（确保外提后仍能执行） if (DT.dominates(I.getParent(), header)) { // 找到header中最后一个非PHI指令的位置插入 auto insertPt = header->getFirstNonPHI(); I.moveBefore(insertPt); } } } } }

isLoopInvariant()的判定规则（严格遵循龙书P502）：

• 指令的操作数全部为常量，或全部为循环外定义的值；
• 指令不调用可能产生副作用的函数（如printf）；
• 指令不是store（除非store的目标是循环外分配的内存）；
• 指令不是load（除非load的地址是循环不变式）。

避坑：LLVM的LoopInfo可能无法识别嵌套循环的内层循环。中科大项目中，LICMPass需先调用LI.analyze(DT)确保循环信息最新，否则L->getBlocks()返回空。

4.2 常量传播（Constant Propagation）：基于数据流方程的迭代求解

常量传播采用迭代算法，维护每个llvm::Value*的ConstantValue映射：

// ConstantPropagationPass.h struct ConstantPropagationPass : public llvm::FunctionPass { static char ID; ConstantPropagationPass() : FunctionPass(ID) {} bool runOnFunction(llvm::Function& F) override; private: std::map<llvm::Value*, llvm::Constant*> constMap; bool iterateOverFunction(llvm::Function& F); llvm::Constant* getConstant(llvm::Value* V); };

iterateOverFunction()按逆后序（Reverse Post Order）遍历基本块，对每条指令求解：

bool ConstantPropagationPass::iterateOverFunction(llvm::Function& F) { bool changed = false; auto rpo = llvm::ReversePostOrderTraversal<llvm::Function>(&F); for (auto BB : rpo) { for (auto& I : *BB) { if (auto* binOp = llvm::dyn_cast<llvm::BinaryOperator>(&I)) { auto* lhs = getConstant(binOp->getOperand(0)); auto* rhs = getConstant(binOp->getOperand(1)); if (lhs && rhs) { auto* result = llvm::ConstantFoldBinaryOpOperands( binOp->getOpcode(), lhs, rhs, F.getContext() ); if (result) { constMap[&I] = result; changed = true; } } } // ... 处理cmp, select, phi等 } } return changed; }

getConstant()处理Phi节点的特殊情况：

llvm::Constant* ConstantPropagationPass::getConstant(llvm::Value* V) { if (auto* C = llvm::dyn_cast<llvm::Constant>(V)) return C; if (constMap.count(V)) return constMap[V]; if (auto* phi = llvm::dyn_cast<llvm::PHINode>(V)) { // Phi节点所有入边值必须相同才视为常量 llvm::Constant* first = nullptr; for (unsigned i = 0; i < phi->getNumIncomingValues(); ++i) { auto* incoming = getConstant(phi->getIncomingValue(i)); if (!incoming) return nullptr; if (!first) first = incoming; else if (first != incoming) return nullptr; } return first; } return nullptr; }

4.3 活跃变量分析（Live Variable Analysis）：基于控制流图的逆向数据流求解

活跃变量分析为后续死代码消除（Dead Code Elimination）提供基础。Pass计算每个llvm::Instruction的liveOut集合：

// LiveVariableAnalysis.h struct LiveVariableAnalysis { std::map<llvm::Instruction*, std::set<llvm::Value*>> liveOut; void run(llvm::Function& F); private: void computeGenKill(llvm::BasicBlock* BB, std::set<llvm::Value*>& gen, std::set<llvm::Value*>& kill); void solveDataFlow(llvm::Function& F); };

computeGenKill()规则（龙书P528）：

• gen: 该块中被使用（use）且未被定义（def）的变量；
• kill: 该块中被定义（def）的变量（因为定义会覆盖之前的值）。

solveDataFlow()采用逆后序迭代：

void LiveVariableAnalysis::solveDataFlow(llvm::Function& F) { // 初始化：所有块liveOut为空 for (auto& BB : F) { liveOut[&BB.back()] = {}; // 以块尾指令为key } bool changed = true; while (changed) { changed = false; // 逆后序遍历 auto rpo = llvm::ReversePostOrderTraversal<llvm::Function>(&F); for (auto BB : rpo) { std::set<llvm::Value*> newLiveOut; // liveOut = union of liveIn of all successors for (auto& succ : llvm::successors(BB)) { if (succ->getFirstNonPHI()) { newLiveOut.insert(liveOut[succ->getFirstNonPHI()].begin(), liveOut[succ->getFirstNonPHI()].end()); } } // liveIn = gen ∪ (liveOut - kill) std::set<llvm::Value*> gen, kill; computeGenKill(BB, gen, kill); std::set<llvm::Value*> liveIn = gen; std::set_difference(newLiveOut.begin(), newLiveOut.end(), kill.begin(), kill.end(), std::inserter(liveIn, liveIn.end())); // 更新liveOut：liveOut = liveIn - def + use（简化版） auto& oldLiveOut = liveOut[&BB.back()]; if (oldLiveOut != newLiveOut) { oldLiveOut = newLiveOut; changed = true; } } } }

注意：实际项目中，liveOut存储在std::map<llvm::Instruction*, std::set<llvm::Value*>>中，键为指令指针，便于后续Pass（如DCE）直接查询某条指令的结果是否活跃。

5. 避坑：LLVM IR优化中的5个致命陷阱与解决方案

5.1 现象：LICM外提后程序崩溃，GDB显示segmentation fault

原因：外提的load指令读取了循环内分配的栈内存（如int temp = a[i];中的temp），而外提后该内存可能已被alloca指令释放或重用。LLVM的alloca在函数入口分配，但若temp是循环内声明的变量，其alloca位于循环体内，外提后load指向无效地址。
解决：在isLoopInvariant()中增加检查——若指令的operand是alloca指令，且该alloca位于循环内，则禁止外提。中科大项目中，通过LI.isLoopInvariant(AllocaInst*)接口判断alloca是否在循环内。

5.2 现象：常量传播后if (0) { ... }分支未被消除，opt -O2却能删掉

原因：ConstantPropagationPass只传播常量，未实现死代码消除（DCE）。LLVM的opt -O2包含DCEPass，而本项目Pass链中未注册DCE。
解决：在main()中Pass Manager注册顺序改为：addPass(LICMPass()) → addPass(ConstantPropagationPass()) → addPass(llvm::createDeadCodeEliminationPass())。中科大评分要求必须展示DCE效果，否则优化项扣分。

5.3 现象：活跃变量分析结果与opt -analyze -live-vars输出不一致

原因：LLVM原生-live-vars分析的是SSA形式的变量（%x = add ...），而本项目分析对象是llvm::Value*指针，未区分同一变量的不同版本（如%x1,%x2）。当存在Phi节点时，getConstant()返回nullptr导致分析中断。
解决：改用llvm::Value*的getName()作为键，而非指针地址。对Phi节点，将其所有入边Value*的getName()合并为虚拟名（如phi_x），并在computeGenKill()中特殊处理Phi的def/use。

5.4 现象：for (int i=0; i<10; i++)外提后，i的初始值被错误替换为10

原因：isLoopInvariant()误判i为不变式，因其在循环头被load，而load的操作数i的alloca在循环外。但i在循环内被store修改，属于def-use链中的def。
解决：isLoopInvariant()必须检查指令的所有operand是否既未被循环内store定义，也未被循环内phi节点定义。中科大项目中，增加isDefinedInLoop(llvm::Value* V, llvm::Loop* L)辅助函数，遍历L内所有store和phi指令。

5.5 现象：编译器生成的可执行文件输出结果与gcc不一致，但IR无语法错误

原因：C-MinusF规定int a[10]的数组索引从0到9，但visitArraySubscript()中GEP的索引计算未做越界检查，导致a[10]访问到a[0]之后的内存（未定义行为）。LLVM不检查数组越界，而gcc的-fsanitize=address会捕获。
解决：在visitArraySubscript()末尾插入运行时检查（教学版可选）：

auto boundCheck = builder.CreateICmpULT(index, llvm::ConstantInt::get(int32Ty, 10)); // 假设已知数组大小 builder.CreateCondBr(boundCheck, loadBB, trapBB);

中科大项目不要求运行时检查，但需在报告中说明此限制。

6. 验证与调优：用真实测试用例驱动优化效果量化与LLVM调试技巧

6.1 构建可复现的测试用例集与性能对比脚本

项目附带test/目录，包含5类测试用例：

• simple.cminusf：基础语法与IR生成验证；
• loop.cminusf：for循环结构与LICM验证；
• const_prop.cminusf：int x=5; y=x+3;常量传播验证；
• live_var.cminusf：int a=1; if(0){a=2;} return a;活跃变量与DCE验证；
• complex.cminusf：嵌套循环+数组访问+函数调用综合验证。

验证脚本verify.sh自动化执行：

#!/bin/bash # verify.sh for f in test/*.cminusf; do echo "=== Testing $f ===" # 1. 编译为LLVM IR ./compiler $f -o ${f%.cminusf}.ll # 2. 应用优化Pass opt -load ./libLICMPass.so -licm -constprop -dce ${f%.cminusf}.ll -o ${f%.cminusf}.opt.ll # 3. 编译为可执行文件 llc ${f%.cminusf}.opt.ll -o ${f%.cminusf}.s gcc ${f%.cminusf}.s -o ${f%.cminusf}.out # 4. 运行并比对输出 ./${f%.cminusf}.out > ${f%.cminusf}.out.txt diff ${f%.cminusf}.out.txt test/expected/$(basename $f .cminusf).txt done

关键技巧：opt命令中-load ./libLICMPass.so必须指定绝对路径或LD_LIBRARY_PATH，否则LLVM找不到自定义Pass。中科大实验环境要求Pass动态库名为lib*.so，且-licm等选项名与RegisterPass中注册名严格一致。

6.2 使用LLVM工具链深度调试IR优化过程

当优化结果异常时，禁用所有优化，逐Pass观察IR变化：

# 查看原始IR ./compiler test/loop.cminusf -o loop.ll # 仅应用LICM opt -load ./libLICMPass.so -licm loop.ll -o loop.licm.ll # LICM + 常量传播 opt -load ./libLICMPass.so -licm -constprop loop.ll -o loop.licm.const.ll # 对比差异 diff loop.ll loop.licm.ll | head -20

利用llvm-dis反汇编二进制bitcode，llvm-as重新汇编：

# 将bitcode转为可读文本IR llvm-dis loop.bc -o loop.ll # 将文本IR转为bitcode llvm-as loop.ll -o loop.bc

血泪经验：LLVM Pass调试最有效的方式是printf大法——在Pass关键路径插入llvm::errs() << "LICM: moving " << I->getOpcodeName() << "\n";，输出到stderr。中科大服务器禁用cout，但llvm::errs()始终可用。

6.3 优化效果量化表格：指令数、基本块数、执行时间对比

对complex.cminusf（含三层嵌套循环）进行量化：

注意：指令数统计用llvm-dis loop.ll \| grep -v "^;" \| wc -l（排除注释行）；基本块数用llvm-dis loop.ll \| grep "define\|br\|switch" \| wc -l粗略估算；执行时间取10次time平均值，消除系统抖动。

我当年在中科大机房调试LICM时，在processLoop()里加了57行llvm::errs()，最终发现DT.dominates()返回false是因为循环头块未被正确识别——根源是visitForStmt()中headerBB的创建

本文还有配套的精品资源，点击获取