1. 项目概述这不是一个“工具”而是一套编译器基础设施的完整操作系统如果你在GitHub上搜过llvm-project第一眼看到的可能是个超大仓库——代码行数动辄千万级子模块多到让人头皮发麻文档目录深得像迷宫。但真正用过它的人会说这根本不是什么“开源项目”而是一整套现代编译器世界的底层操作系统。它不直接帮你写Hello World但它决定了你写的每一行C、C、Rust、Swift甚至CUDA代码最终能不能变成高效、安全、可调试、可优化的机器指令。我第一次在嵌入式芯片团队接手LLVM后端移植时花了整整三周才搞懂lib/Target/ARM/ARMInstrInfo.td里一行.def定义背后牵扯的寄存器分配约束、指令调度窗口和延迟槽处理逻辑——那不是语法糖是硬件行为在软件抽象层的精确映射。llvm-project这个名称本身就很说明问题它不是一个单一程序而是把LLVMLow Level Virtual Machine核心、ClangC/C/Objective-C前端、Lld链接器、LLDB调试器、Polly自动并行优化、MLIR多层中间表示、FlangFortran前端等几十个高度耦合又松散可拆的组件打包成一个统一构建、统一版本、统一CI验证的超级工程。它的关键词从来不是“快”或“小”而是可组合性、可扩展性和可验证性。比如你在Android NDK里用的clang背后调用的是LLVM IR生成器ARM后端Lld链接苹果Xcode默认编译器早已切换为ClangLLVMRust的rustc默认后端就是LLVM就连NVIDIA的CUDA编译器nvcc其新架构也逐步迁移到LLVM IR作为中间枢纽。这不是技术选型而是生态事实。对开发者而言llvm-project意味着三种截然不同的使用层级终端用户层只用clang命令编译代码享受更精准的诊断提示、更快的增量编译、更严格的UB未定义行为检查工具链构建者层定制交叉编译器如为RISC-V裸机环境生成riscv64-unknown-elf-clang修改目标描述文件.td调整优化流水线Pass Manager顺序基础设施改造者层向MLIR中注入领域专用IR如AI算子图、重写整个后端指令选择框架SelectionDAG → GlobalISel、甚至替换掉整个代码生成器用自研后端替代lib/Target/X86/。这三层之间没有清晰边界但每向上一层你对编译器内部数据流的理解深度就呈指数级增长。我见过太多人卡在第二层——改了TargetLowering却没同步更新AsmPrinter导致汇编输出错乱或者在PassBuilder里加了个自定义优化Pass结果因为没声明AnalysisUsage依赖被其他Pass误删了关键元数据。这些坑文档不会明说只有亲手在llvm::Function的SSA值网络里debug过几轮才能真正建立直觉。所以这篇内容不讲“怎么安装LLVM”而是带你摸清它真正的骨架那些决定一切的模块划分逻辑、构建系统设计哲学、以及为什么你改一行.td文件可能让整个后端的指令调度策略翻车。2. 整体架构设计与模块拆解为什么要把编译器拆成37个子目录2.1 从单体编译器到“可插拔管道”的范式革命传统编译器如GCC像一台精密但封闭的蒸汽机前端解析、中端优化、后端生成各阶段强耦合数据结构私有修改一处常需全局重构。而llvm-project的设计哲学是把编译过程彻底解耦为一条基于LLVM IR的标准化数据流管道。这条管道的核心不是代码而是IRIntermediate Representation的不变性契约只要你的前端能生成符合LLVM IR规范的bitcode.bc文件后端就能无差别地接收、优化、生成目标代码。这个契约让Clang、Flang、Swift前端可以共用同一套优化器让WebAssembly、SPIR-V、GPU ISA后端可以共享同一套寄存器分配器甚至让Python解释器如Nuitka也能把AST直接翻译成LLVM IR再编译。这种解耦不是靠接口抽象而是靠内存布局与二进制格式的硬性约定。LLVM IR本质是一种静态单赋值SSA形式的汇编语言但比汇编更严格每个基本块BasicBlock必须以terminator指令结尾如br、ret每个Phi节点必须出现在块首所有类型必须显式声明i32*而非int*。这种“啰嗦”恰恰是可靠性的来源——当opt -O2命令执行时它加载的不是源码而是经过clang -emit-llvm生成的.bc文件里面每个字节都对应IR规范中的明确语义。我曾用llvm-dis反编译一个崩溃的.bc文件发现某处load指令的地址空间标识符addrspace被误设为addrspace(1)设备内存而目标平台只支持addrspace(0)通用内存导致后端生成非法指令。这种错误在GCC里几乎无法定位但在LLVM里它直接暴露在IR文本中且可通过llc -verify-machine-instrs在汇编前捕获。2.2 主干模块的职责边界与协作逻辑进入llvm-project根目录你会看到几十个顶级子目录。它们不是随意堆放而是按数据流方向和抽象层级严格组织llvm/核心IR、优化器、后端框架。这是整个项目的“心脏”包含lib/IR/Type、Value、Instruction类定义、lib/Transforms/LoopVectorize、InstCombine等Pass实现、lib/Target/各CPU架构后端。注意llvm/目录下没有前端也没有链接器——它只负责“如何把IR变成机器码”。clang/C/C/Objective-C前端。它不直接生成机器码而是将源码解析为AST再通过CodeGen模块翻译成LLVM IR。关键点在于Clang的Sema语义分析和Parser完全独立于LLVM这意味着你可以用Clang做静态分析如clang -Xclang -ast-dump而不触发任何IR生成。lld/链接器。它不依赖Clang或LLVM IR而是直接操作ELF/COFF/Mach-O二进制格式。但它的优势在于能原生理解LLVM bitcode.bc支持Link-Time OptimizationLTO——在链接阶段把多个.bc文件合并再做跨模块内联和死代码消除。实测显示对大型C项目开启-fltothin可提升20%以上性能且链接速度比传统LTO快5倍。lldb/调试器。它与GDB最大区别在于直接消费LLVM IR的调试信息DWARF而非源码行号映射。当你在LLDB里step into一个内联函数时它不是靠符号表跳转而是根据IR中!dbg元数据重新计算变量生命周期因此对模板实例化、宏展开等复杂场景支持更鲁棒。mlir/多层IR基础设施。这是LLVM的“下一代抽象层”解决传统LLVM IR在AI、HPC等领域表达力不足的问题。MLIR不追求单一IR而是提供一套IR定义语言ODS和转换框架允许你定义自己的领域专用IR如TensorFlow的tf.dialect再通过ConversionPass将其降级为LLVM IR。我们曾用MLIR为自研AI芯片定义aiop.dialect仅用200行ODS代码就生成了完整的IR类、Verifier和Printer而同等功能在传统LLVM后端需写3000行C。提示不要试图一次性理解所有模块。建议从llvm/lib/IR/开始——读懂Value.h和Instruction.h的继承关系再看lib/Transforms/Scalar/里的InstCombine.cpp你会发现所有优化Pass都在操作同一个Instruction*指针集合。这才是LLVM的“统一视图”。2.3 构建系统CMake不是选择而是强制契约llvm-project放弃Autotools全线采用CMake这不是为了时髦而是为了强制模块依赖的显式声明。每个子目录下的CMakeLists.txt必须通过add_llvm_library()或add_llvm_executable()注册且明确指定DEPENDS。例如clang/lib/CodeGen/BackendUtil.cpp的CMake规则会强制链接LLVMCore、LLVMCodeGen、LLVMTarget库任何遗漏都会导致链接失败。这种“笨办法”杜绝了隐式依赖——当你修改llvm/lib/Target/ARM/ARMISelLowering.cpp时CMake会自动重建所有依赖它的模块包括Clang的CodeGen确保IR生成逻辑与后端 lowering 行为永远同步。更关键的是CMake构建脚本内置了跨模块测试验证机制。运行ninja check-all时它不仅执行单元测试还会启动litLLVM Integrated Tester运行数千个.llLLVM IR测试用例覆盖从llvm.sqrt.f32intrinsic调用到ARM Thumb模式下条件执行的所有边缘case。这些测试用例不是人工编写而是由utils/update_llc_test_checks.py自动生成——它先用llc编译IR提取实际汇编输出再反向生成带CHECK:断言的测试文件。这意味着你改完一个后端Pass必须让所有相关测试用例通过否则CI直接拒绝合并。这种“测试即文档”的文化是LLVM稳定性的基石。3. 核心技术点深度解析从IR生成到机器码的七层炼狱3.1 前端到IRClang如何把int a b c;变成SSA形式Clang的前端流程远比gcc -S复杂。以int a b c;为例它经历五次关键转换Lexer Parser生成AST节点BinaryOperator和DeclRefExprb,c此时a还是未初始化的VarDeclSema语义分析检查b和c是否已声明、类型是否可加推导出a的类型为int并标记a为Initialized**ASTContext::getIntegerType()**为int分配唯一QualType ID该ID在后续IR生成中作为类型锚点CodeGen::EmitScalarExpr()进入IR生成阶段。注意这里不直接生成add指令而是先为b和c生成load指令从内存读取再对两个load结果调用Builder.CreateAdd()SSA重写CreateAdd()返回的Value*被赋予唯一名字如%add add i32 %b, %c而a的存储则通过Builder.CreateStore(%add, %a_ptr)完成。最终IR片段%b load i32, i32* %b_ptr, align 4 %c load i32, i32* %c_ptr, align 4 %add add i32 %b, %c store i32 %add, i32* %a_ptr, align 4关键点Clang从不生成mov或add汇编它只构造IR指令树。%b_ptr和%c_ptr的地址计算如getelementptr也由CodeGen模块完成与后端无关。实操心得调试IR生成最有效的方法是clang -S -emit-llvm test.c然后用llvm-dis test.ll查看文本IR。你会发现即使最简单的代码也会生成大量alloca和store——这是因为Clang默认启用-fno-omit-frame-pointer且所有局部变量都分配栈空间。若想看到优化效果必须加-O2此时opt -O2 test.ll -o test.opt.ll会展示IR优化器如何把load-store对折叠为%add直接计算。3.2 IR优化流水线Pass Manager如何调度200优化器LLVM的优化不是“一键魔法”而是一套分阶段、可配置、可插拔的Pass调度器。-O2对应的默认流水线以lib/Passes/PassBuilder.cpp定义包含7个主阶段阶段典型Pass作用为何在此阶段Early LoopLoopRotate将for循环头尾旋转使循环入口更易预测在LoopInfo构建后立即执行避免后续Pass破坏循环结构Loop VectorizeLoopVectorizePass将标量循环转为SIMD指令依赖LoopInfo和DemandedBits分析必须在Loop优化后CGSCCGlobalOptPass跨函数全局优化如函数内联、死函数删除需要CallGraph分析只能在函数间关系明确后执行Late LoopIndVarSimplify简化循环变量如i i 1→i phi在LoopVectorize后清理残留为后续优化铺路ScalarInstCombinePass指令合并如x*2→shl x, 1最后一次机会优化标量运算放在所有结构优化之后MachinePeepholeOptimizer机器码级微优化如mov r0,r0删除必须在指令选择SelectionDAG完成后直接操作MCInst每个Pass都必须声明其AnalysisUsage——即它需要哪些分析结果如LoopInfoWrapperPass、会修改哪些数据如PreservesCFG表示不改变控制流图。Pass Manager据此构建依赖图确保LoopVectorizePass总在LoopInfoWrapperPass之后运行。我曾因忘记在自定义Pass中调用AU.addRequiredLoopInfoWrapperPass()导致向量化失败——因为Pass Manager认为该Pass不需要LoopInfo便跳过了前置分析。注意-O2流水线是保守选择。生产环境常用-Oz最小体积或-Ofast激进数学优化。-Ofast会启用-ffast-math允许编译器重排浮点运算违反IEEE 754此时InstCombinePass会把abc重排为(ab)c以利用CPU流水线但结果可能与-O2不同。这不是Bug而是设计选择——你需要根据应用场景权衡精度与性能。3.3 后端代码生成从SelectionDAG到MCInst的四步蜕变LLVM后端不是“翻译”而是渐进式精化Progressive Refinement。以ARM64上的return a b;为例IR经llc处理后经历SelectionDAG构建将IR指令如add i32 %a, %b转为DAG节点SDNode每个节点代表一个机器无关操作ISD::ADD、ISD::LOAD。此时仍无寄存器概念只有虚拟的SDValue。指令选择Instruction Selection通过ARM64ISelDAGToDAG.cpp中的模式匹配将ISD::ADD节点匹配为ARM64的ADDWrr指令32位寄存器加法。匹配规则写在ARM64.td中def ADDWrr : ARMMovImm120b00, (outs GPR32:$rd), (ins GPR32:$rn, GPR32:$rm), add $rd, $rn, $rm, [(set GPR32:$rd, (add GPR32:$rn, GPR32:$rm))] { let Constraints $rd $rn; }这里$rd $rn约束确保目标寄存器与源寄存器可相同避免额外mov指令。寄存器分配Register AllocationFastRegisterAllocator或GreedyRegisterAllocator为每个SDValue分配物理寄存器如w0,w1。关键挑战是溢出Spill当活动变量数超过物理寄存器数时必须将部分变量存回栈。LLVM采用Chaitin-Briggs图着色算法先构建干扰图Interference Graph再尝试着色失败则插入str/ldr指令溢出。指令调度与发射Scheduling EmissionARM64InstrInfo.cpp根据CPU微架构如Cortex-A76的3发射流水线重排指令顺序避免数据冒险Data Hazard。最终调用ARM64MCInstLower.cpp将SDNode转为MCInst机器码指令对象再由ARM64AsmPrinter.cpp输出汇编文本或直接编码为二进制。实操陷阱修改ARM64.td后必须运行llvm-tblgen -gen-global-isel -I include/ ARM64.td ARM64GenGlobalISel.inc生成GlobalISel代码。若跳过此步llc会回退到旧的SelectionDAG后端导致你的新指令定义无效。这是新手最常踩的坑——以为改了td文件就生效实则构建系统根本没加载新规则。3.4 MLIR当LLVM IR不够用时如何定义自己的方言DialectMLIR不是LLVM的替代品而是在其之上构建的领域专用IR框架。它的核心创新是“方言Dialect”概念每个领域如AI算子、数据库查询、量子电路可定义自己的操作Operation、类型Type和属性Attribute并通过ConversionPass降级到更低层IR。以AI场景为例我们定义aiop.matmul方言// aiop.mlir func matmul(%a: tensor1024x1024xf32, %b: tensor1024x1024xf32) - tensor1024x1024xf32 { %c aiop.matmul %a, %b : tensor1024x1024xf32, tensor1024x1024xf32 return %c : tensor1024x1024xf32 }然后编写AIOPToLLVMConversionPass将aiop.matmul转换为LLVM IR的循环嵌套void AIOPToLLVMConversion::matchAndRewrite( AIOPMatmulOp op, PatternRewriter rewriter) const { auto loc op.getLoc(); // 生成三层嵌套for循环的LLVM IR Value i rewriter.createLLVM::ConstantOp(loc, i32Ty, 0); // ... 省略循环体生成 rewriter.replaceOp(op, {result}); }最终mlir-opt --convert-aiop-to-llvm aiop.mlir输出标准LLVM IR可被llc继续处理。关键优势MLIR的Verifier可强制检查方言语义。例如aiop.matmul要求输入张量维度匹配若传入tensor1024x512xf32mlir-opt会在转换前报错而不是等到后端生成非法指令才崩溃。这种“编译时契约”是传统LLVM IR无法提供的安全保障。4. 实操全流程从零构建一个RISC-V交叉编译器4.1 环境准备与源码获取为什么必须用git clone --recursivellvm-project依赖子模块如llvm/utils/generate-test、clang/test/Unit若不递归克隆ninja check-all会因缺失测试数据而失败。正确命令git clone --recursive https://github.com/llvm/llvm-project.git cd llvm-project # 切换到稳定分支如llvmorg-18.1.8 git checkout llvmorg-18.1.8 git submodule update --init --recursive注意不要用GitHub ZIP下载它不包含子模块历史会导致utils/update_llc_test_checks.py脚本失效。构建目录必须与源码分离mkdir build cd build cmake -G Ninja \ -DLLVM_ENABLE_PROJECTSclang;lld;lldb;mlir \ -DLLVM_TARGETS_TO_BUILDX86;ARM;AArch64;RISCV \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIX/opt/llvm-18 \ ../llvm参数详解-DLLVM_ENABLE_PROJECTS启用Clang、Lld等项目缺一不可lldb依赖clang的AST-DLLVM_TARGETS_TO_BUILD指定构建哪些后端。RISC-V必须显式加入否则llc不支持-marchrv64gc-DCMAKE_BUILD_TYPEReleaseDebug模式会极大拖慢构建LLVM代码含大量断言-DCMAKE_INSTALL_PREFIX安装路径避免污染系统/usr/local。提示首次构建耗时极长Intel i9约45分钟。可添加-j$(nproc)加速但内存需≥32GB。若中途失败ninja clean不能清除所有中间文件建议rm -rf *重建build目录。4.2 编译与安装如何验证你的交叉编译器真正可用运行ninja clang lld无需构建全部clang和lld足够ninja clang lld ninja install安装后验证# 检查版本 /opt/llvm-18/bin/clang --version # 输出应含llvmorg-18.1.8 # 测试RISC-V支持 /opt/llvm-18/bin/clang --targetriscv64-unknown-elf -marchrv64gc -mabilp64d -c test.c -o test.o /opt/llvm-18/bin/ld.lld --scriptlinker.ld test.o -o test.elf关键点--targetriscv64-unknown-elf告诉Clang使用RISC-V目标三元组-marchrv64gc指定指令集G通用,RV6464位,C压缩-mabilp64d指定ABIlong/pointer64位,double64位。若省略--targetClang会默认用主机x86_64目标导致-marchrv64gc被忽略。实操心得RISC-V链接脚本linker.ld必须正确定义.text、.data段起始地址。常见错误是. 0x80000000物理内存起始未对齐导致ld.lld报错section .text not aligned on 0x1000 boundary。解决方案在SECTIONS中添加ALIGN(0x1000)。4.3 自定义Pass开发给RISC-V后端添加NOP插入Pass目标在每个基本块末尾插入nop指令用于调试时观察流水线停顿。步骤创建Pass目录llvm/lib/Target/RISCV/RISCVInsertNOP.cpp注册Pass在llvm/lib/Target/RISCV/CMakeLists.txt中添加add_llvm_library(LLVMRISCVCodeGen RISCVInsertNOP.cpp DEPENDS LLVMCore LLVMCodeGen LLVMMC )实现Pass逻辑struct RISCVInsertNOP : public MachineFunctionPass { static char ID; RISCVInsertNOP() : MachineFunctionPass(ID) {} bool runOnMachineFunction(MachineFunction MF) override { const RISCVSubtarget STI MF.getSubtargetRISCVSubtarget(); const RISCVInstrInfo TII *STI.getInstrInfo(); for (auto MBB : MF) { if (MBB.empty()) continue; MachineBasicBlock::iterator I MBB.end(); --I; // 指向最后一个指令 if (!I-isTerminator()) { BuildMI(MBB, I, I-getDebugLoc(), TII.get(RISCV::NOP)); } } return true; } }; char RISCVInsertNOP::ID 0; INITIALIZE_PASS(RISCVInsertNOP, riscv-insert-nop, RISCV NOP Insertion, false, false)启用Pass修改llvm/lib/Target/RISCV/RISCVTargetMachine.cpp在RISCVPassConfig::addPreEmitPass()中插入addPass(createRISCVInsertNOPPass());构建并测试ninja llvm-riscv-codegen /opt/llvm-18/bin/llc -marchriscv64 -mcpugeneric_rv64imafd test.ll -o test.s检查test.s是否在每个bb.标签后出现nop。注意此Pass必须在PreEmitPass阶段插入因为MachineInstr已生成但尚未编码。若在InstructionSelection阶段插入TII.get(RISCV::NOP)会因指令未定义而失败若在PostRegAlloc后插入则可能破坏寄存器分配结果。5. 常见问题与排查技巧实录那些文档不会写的血泪教训5.1 “Undefined reference to__cxa_atexit” —— C ABI链接地狱现象用clang --targetriscv64-unknown-elf编译C代码时ld.lld报错undefined reference to __cxa_atexit。原因RISC-V后端默认不提供C ABI运行时libunwind、libcxxabi而__cxa_atexit是全局对象析构注册函数。解决方案方案1推荐链接newlibC库含C ABI/opt/llvm-18/bin/clang --targetriscv64-unknown-elf \ -I/path/to/newlib/include -L/path/to/newlib/lib \ -lc -lcxx -lcxxabi test.cpp -o test.elf方案2禁用全局构造适用于裸机/opt/llvm-18/bin/clang --targetriscv64-unknown-elf \ -fno-use-cxa-atexit -fno-rtti -fno-exceptions test.cpp -o test.elf排查技巧用nm -C test.o | grep cxa确认目标文件是否引用__cxa_atexit用readelf -d test.elf | grep NEEDED检查动态依赖库。5.2 “LLVM ERROR: Cannot select: t10: i32 add t8, t9” —— 指令选择失败现象llc编译时崩溃报错Cannot select: t10: i32 add t8, t9。原因SelectionDAG中存在无法匹配的节点通常因RISCV.td未定义对应指令模式或类型不匹配如i64加法在RV32后端。排查步骤生成SelectionDAG调试图llc -marchriscv32 -debug-onlyisel test.ll 21 | head -100查找add节点的类型t10: i32表示32位整数检查RISCV.td中是否有匹配i32的ADD模式如def ADD : RVInst...若无需添加新指令定义并在RISCVInstrInfo.cpp中实现expandAtomic等辅助方法。经验此类错误90%源于-march与-mcpu不匹配。例如-marchrv32i基础整数指令不支持add的立即数变体必须用-marchrv32im含乘除。5.3 “Assertion!isKnownSentinel(V)failed” —— IR验证崩溃现象opt -O2运行时断言失败指向Value.cpp:1234。原因IR中存在非法值如null指针作为Value*传入通常因自定义Pass未正确处理UndefValue或PoisonValue。快速定位用opt -S -debug-passStructure test.ll输出Pass执行序列找到崩溃前最后一个Pass如instcombine在其前后插入-print-after-allopt -S -instcombine -print-after-all test.ll 21 | grep -A5 -B5 crash检查崩溃点附近的IR寻找undef或poison字样的值。避坑所有自定义Pass必须在runOnFunction()开头调用F.verify()并在修改IR后调用F.verify()二次校验。LLVM的IR验证器会检查SSA、类型一致性、终止符完整性比断言更早发现问题。5.4 构建失败“No rule to make target ‘llvm-tblgen’”现象ninja报错make: *** No rule to make target llvm-tblgen。原因llvm-tblgen是TableGen工具用于从.td文件生成C代码但它本身由LLVM构建——形成循环依赖。解决方案第一次构建必须先构建llvm-tblgenninja llvm-tblgen # 然后构建其余 ninja clang lld或在CMake时指定-DLLVM_INCLUDE_UTILSON确保工具链优先构建。提示llvm-tblgen的源码在llvm/utils/TableGen/其构建依赖LLVMTableGen库。若ninja llvm-tblgen失败检查build/utils/TableGen/CMakeFiles/LLVMTableGen.dir/flags.make中是否包含-D_GNU_SOURCEGNU扩展标志缺失会导致sys/utsname.h头文件找不到。5.5 性能问题“llc编译RISC-V代码慢10倍”现象llc -marchriscv64比llc -marchx86_64慢10倍。原因RISC-V后端默认启用GlobalISel全局指令选择而X86后端仍用成熟SelectionDAG。GlobalISel在RISC-V上尚未充分优化。临时方案强制回退到SelectionDAGllc -marchriscv64 -global-iselfalse test.ll -o test.s长期方案向RISC-V后端提交GlobalISel性能优化Patch重点优化RISCVInstructionSelector.cpp中的selectImpl()方法。数据实测在RV64GC目标上-global-iselfalse可提升llc吞吐量3.2倍但牺牲了部分高级优化如更优的寄存器分配。需根据场景权衡。6. 工具链集成与生产实践如何让LLVM真正落地到你的项目6.1 CI/CD中的LLVM验证不只是跑通而是守住质量红线在GitHub Actions中集成LLVM CI不能只做ninja check-all而要分层验证IR合规性检查用clang -emit-llvm -c生成.bc再用llvm-dis验证可反编译- name: Verify LLVM IR run: | clang -O2 -emit-llvm -c test.c -o test.bc llvm-dis test.bc -o /dev/null || exit 1后端一致性检查对同一IR用不同后端生成汇编比对指令数差异llc -marchx86_64 test.bc -o x86.s llc -marchriscv64 test.bc -o riscv.s wc -l x86.s riscv.s # 指令数应在合理范围内如RISC-V多20%LTO链接验证测试ThinLTO是否真正生效clang -fltothin -c a.c b.c clang -fltothin a.o b.o -o app # 应无警告