LLVM 是一个自由软件项目，它是一种编译器基础设施，以 C++ 写成，包含一系列模块化的编译器组件和工具链，用来开发编译器前端和后端。它是为了任意一种编程语言而写成的程序，利用虚拟技术创造出编译时期、链接时期、运行时期以及“闲置时期”的最优化。它最早以 C/C++ 为实现对象，而当前它已支持包括 ActionScript、Ada、D语言、Fortran、GLSL、Haskell、Java字节码、Objective-C、Swift、Python、Ruby、Crystal、Rust、Scala 以及 C# 等语言。
— 维基百科
2000年，伊利诺伊大学厄巴纳－香槟分校（University of Illinois at Urbana-Champaign 简称UIUC）这所享有世界声望的一流公立研究型大学的 Chris Lattner（他的 twitter @clattner_llvm ） 开发了一个叫作 Low Level Virtual Machine 的编译器开发工具套件，后来涉及范围越来越大，可以用于常规编译器，JIT编译器，汇编器，调试器，静态分析工具等一系列跟编程语言相关的工作，于是就把简称 LLVM 这个简称作为了正式的名字。Chris Lattner 后来又开发了 Clang，使得 LLVM 直接挑战 GCC 的地位。2012年，LLVM 获得美国计算机学会 ACM 的软件系统大奖，和 UNIX，WWW，TCP/IP，Tex，JAVA 等齐名。
— 深入剖析 iOS 编译 Clang / LLVM
对于 iOS 开发者来说，Swift 之父 Chris Lattner 的大名应该都会有所耳闻。他和他的团队所开发的 LLVM 已经成为 iOS 乃至 macOS 整个生态中至关重要的底层基础设施。虽然 Lattner 本人已经去 Google 做人工智能了，但是对于 iOS 开发者了解并掌握一些关于 LLVM 的基本知识还是很有必要的。
LLVM 初探
LLVM 的官网是 http://llvm.org/。通过官网我们可以看到，LLVM 其实是一系列的编译组件的集合。而 Clang (标准读法是 克朗) 是作为其中的前端。这里的前端并不是 HTML5 这样的前端概念。说到这里，我们来简单回顾下传统编译器的设计吧。
传统编译器
在 LLVM 诞生之前，使用最广泛的应该是 GCC 编译器了，当然，GCC 在当下仍然扮演着很重要的角色。
编译器前端 Front End
编译器前端的任务是解析源代码，具体工作内容包括下列三个流程
- 词法分析
- 语法分析
- 语义分析
检查源代码是否存在错误，然后构建抽象语法树(Abstract Syntax Tree, AST)。
LLVM的前端还会生成中间代码(intermediate representation, IR)。
优化器 Optimizer
优化器负责进行各种优化。改善代码的运行时间，例如消除冗余计算等。
编译器后端 Back End
将代码映射到目标指令集。生成机器语言，并且进行机器相关的代码优化。
有些资料也会把编译器后端成为 代码生成器 Code Generator。
从上面的内容可以看到，传统的编译器架构前端和后端之间耦合度太高，如果要支持一门新的编程语言，或者一个新的目标平台，工作量会非常大。
LLVM 架构
LLVM 之所以能够成为编译器中的中流砥柱，最重要的就是使用了通用的代码表现形式，也就是 IR。有了 IR，LLVM 就可以为任何编程语言独立编写前端，并且可以为任意硬件架构独立编写后端。
Clang
Clang 是 LLVM 项目中的一个子项目。它是基于 LLVM 架构的轻量级编译器，诞生之初是为了替代 GCC，提供更快的编译速度。它是负责编译 C、C++、Objective-C 语言的编译器，它属于整个 LLVM 架构中的编译器前端。对于我们来说，研究 Clang 可以让我们更深刻的理解从源码到汇编再到机器码的这一过程。
Clang 的官网地址是 http://clang.llvm.org/
相比于 GCC，Clang 具有以下优点
- 编译速度快：在某些平台上，Clang的编译速度显著的快过GCC（Debug模式下编译OC速度比GGC快3倍）
- 占用内存小：Clang生成的AST所占用的内存是GCC的五分之一左右
- 模块化设计：Clang采用基于库的模块化设计，易于 IDE 集成及其他用途的重用
- 诊断信息可读性强：在编译过程中，Clang 创建并保留了大量详细的元数据 (metadata)，有利于调试和错误报告
- 设计清晰简单，容易理解，易于扩展增强
也就是说，广义上的 LLVM 指的是整个 LLVM 架构，而狭义上的 LLVM 是指的 LLVM 后端。
而 LLVM 后端包括代码优化(优化器)和目标代码生成(后端)两个部分。
iOS 中的编译过程
在探索编译过程之前，我们先通过一个命令来打印出源码的编译阶段
clang -ccc-print-phases 文件名
打印输出如下
0: input, "main.m", objective-c1: preprocessor, {0}, objective-c-cpp-output2: compiler, {1}, ir3: backend, {2}, assembler4: assembler, {3}, object5: linker, {4}, image6: bind-arch, "x86_64", {5}, image
从结果可以看到，一共分为 7 大阶段。
- input: 输入阶段，表示将 main.m 文件输入，文件格式是 OC
- preprocessor: 预处理阶段，这个过程包括宏的替换，头文件的导入
- compiler：编译阶段，进行词法分析、语法分析、语义分析，最终生成 IR
- backend: 后端，LLVM 会通过一个一个的 Pass 去优化，最终生成汇编代码。
- assembler: 汇编，生成目标文件
- linker: 链接，链接需要的动态库和静态库，生成可执行文件
- bind-arch: 架构绑定，通过不同的架构，生成对应的可执行文件
预处理阶段
clang -E 文件名 -o 输出文件名
我们可以通过上面的 clang 命令来执行预处理阶段并输出到一个文件中。
我们可以测试一下，在 main.m 中代码如下
// main.m#include <stdio.h>#define C 30int main(int argc, const char * argv[]) {@autoreleasepool {int a = 10;int b = 20;printf("%d", a + b + C);}return 0;}
然后执行
clang -E main.m -i main2.m
可以查看一下 main2.m 文件的内容:
可以看到，宏已经被替换了，并且 stdio.h 头文件也被导入进来了。
那像 typedef 这样的命令是否也会在预处理阶段被替换了，我们可以测试一下:
#include <stdio.h>#define C 30typedef int JH_INT_64;int main(int argc, const char * argv[]) {@autoreleasepool {JH_INT_64 a = 10;JH_INT_64 b = 20;printf("%d", a + b + C);}return 0;}
还是执行同样的命令
clang -E main.m -o main3.m
结果如下
可以看到，typedef 并没有被替换掉，原因在于 typedef 只是一个别名，并不属于宏定义的范畴。
编译阶段
经过预处理阶段之后，源文件需要被编译生成相应的中间代码 IR。
但我们知道其实整个编译阶段是分为 词法分析、语法分析 两个阶段。
词法分析
预处理完成后就会进行词法分析，代码会被切成一个个 Token，比如大小括号，等于号和字符串。
词法分析命令如下
clang -fmodules -fsyntax-only -Xclang -dump-tokens 文件名
我们测试一下
clang -fmodules -fsyntax-only -Xclang -dump-tokens main.m
终端输出结果如下
annot_module_include '#include <stdio.h>#define C 30typedef int JH_INT_64;int main(int argc, const char * argv[]) {@autoreleasepool {JH_INT_64 a ' Loc=<main.m:9:1>typedef 'typedef' [StartOfLine] Loc=<main.m:12:1>int 'int' [LeadingSpace] Loc=<main.m:12:9>identifier 'JH_INT_64' [LeadingSpace] Loc=<main.m:12:13>semi ';' Loc=<main.m:12:22>int 'int' [StartOfLine] Loc=<main.m:13:1>identifier 'main' [LeadingSpace] Loc=<main.m:13:5>l_paren '(' Loc=<main.m:13:9>int 'int' Loc=<main.m:13:10>identifier 'argc' [LeadingSpace] Loc=<main.m:13:14>comma ',' Loc=<main.m:13:18>const 'const' [LeadingSpace] Loc=<main.m:13:20>char 'char' [LeadingSpace] Loc=<main.m:13:26>star '*' [LeadingSpace] Loc=<main.m:13:31>identifier 'argv' [LeadingSpace] Loc=<main.m:13:33>l_square '[' Loc=<main.m:13:37>r_square ']' Loc=<main.m:13:38>r_paren ')' Loc=<main.m:13:39>l_brace '{' [LeadingSpace] Loc=<main.m:13:41>at '@' [StartOfLine] [LeadingSpace] Loc=<main.m:14:5>identifier 'autoreleasepool' Loc=<main.m:14:6>l_brace '{' [LeadingSpace] Loc=<main.m:14:22>identifier 'JH_INT_64' [StartOfLine] [LeadingSpace] Loc=<main.m:15:9>identifier 'a' [LeadingSpace] Loc=<main.m:15:19>equal '=' [LeadingSpace] Loc=<main.m:15:21>numeric_constant '10' [LeadingSpace] Loc=<main.m:15:23>semi ';' Loc=<main.m:15:25>identifier 'JH_INT_64' [StartOfLine] [LeadingSpace] Loc=<main.m:16:9>identifier 'b' [LeadingSpace] Loc=<main.m:16:19>equal '=' [LeadingSpace] Loc=<main.m:16:21>numeric_constant '20' [LeadingSpace] Loc=<main.m:16:23>semi ';' Loc=<main.m:16:25>identifier 'printf' [StartOfLine] [LeadingSpace] Loc=<main.m:17:9>l_paren '(' Loc=<main.m:17:15>string_literal '"%d"' Loc=<main.m:17:16>comma ',' Loc=<main.m:17:20>identifier 'a' [LeadingSpace] Loc=<main.m:17:22>plus '+' [LeadingSpace] Loc=<main.m:17:24>identifier 'b' [LeadingSpace] Loc=<main.m:17:26>plus '+' [LeadingSpace] Loc=<main.m:17:28>numeric_constant '30' [LeadingSpace] Loc=<main.m:17:30 <Spelling=main.m:11:11>>r_paren ')' Loc=<main.m:17:31>semi ';' Loc=<main.m:17:32>r_brace '}' [StartOfLine] [LeadingSpace] Loc=<main.m:18:5>return 'return' [StartOfLine] [LeadingSpace] Loc=<main.m:19:5>numeric_constant '0' [LeadingSpace] Loc=<main.m:19:12>semi ';' Loc=<main.m:19:13>r_brace '}' [StartOfLine] Loc=<main.m:20:1>eof '' Loc=<main.m:20:2>
可以看到，main.m 中的代码都被拆解成了一个一个 token。
语法分析
词法分析完成之后就是语法分析。它的任务是验证语法是否正确。在词法分析的基础上将单词序列组合成各类词法短语。如 程序、语句、表达式等，然后将所有的节点组成抽象语法树(Abstract Syntax Tree, AST)。
语法分析命名如下
clang -fmodules -fsyntax-only -Xclang -ast-dump 文件名
我们测试一下
clang -fmodules -fsyntax-only -Xclang -ast-dump main.m
终端打印结果如下
TranslationUnitDecl 0x7fa0aa017408 <<invalid sloc>> <invalid sloc>|-TypedefDecl 0x7fa0aa017ca0 <<invalid sloc>> <invalid sloc> implicit __int128_t '__int128'| `-BuiltinType 0x7fa0aa0179a0 '__int128'|-TypedefDecl 0x7fa0aa017d08 <<invalid sloc>> <invalid sloc> implicit __uint128_t 'unsigned __int128'| `-BuiltinType 0x7fa0aa0179c0 'unsigned __int128'|-TypedefDecl 0x7fa0aa017da0 <<invalid sloc>> <invalid sloc> implicit SEL 'SEL *'| `-PointerType 0x7fa0aa017d60 'SEL *'| `-BuiltinType 0x7fa0aa017c00 'SEL'|-TypedefDecl 0x7fa0aa017e78 <<invalid sloc>> <invalid sloc> implicit id 'id'| `-ObjCObjectPointerType 0x7fa0aa017e20 'id'| `-ObjCObjectType 0x7fa0aa017df0 'id'|-TypedefDecl 0x7fa0aa017f58 <<invalid sloc>> <invalid sloc> implicit Class 'Class'| `-ObjCObjectPointerType 0x7fa0aa017f00 'Class'| `-ObjCObjectType 0x7fa0aa017ed0 'Class'|-ObjCInterfaceDecl 0x7fa0aa017fa8 <<invalid sloc>> <invalid sloc> implicit Protocol|-TypedefDecl 0x7fa0aa0182e8 <<invalid sloc>> <invalid sloc> implicit __NSConstantString 'struct __NSConstantString_tag'| `-RecordType 0x7fa0aa018100 'struct __NSConstantString_tag'| `-Record 0x7fa0aa018070 '__NSConstantString_tag'|-TypedefDecl 0x7fa0aa018380 <<invalid sloc>> <invalid sloc> implicit __builtin_ms_va_list 'char *'| `-PointerType 0x7fa0aa018340 'char *'| `-BuiltinType 0x7fa0aa0174a0 'char'|-TypedefDecl 0x7fa0aa054e68 <<invalid sloc>> <invalid sloc> implicit __builtin_va_list 'struct __va_list_tag [1]'| `-ConstantArrayType 0x7fa0aa054e10 'struct __va_list_tag [1]' 1| `-RecordType 0x7fa0aa054c90 'struct __va_list_tag'| `-Record 0x7fa0aa054c00 '__va_list_tag'|-ImportDecl 0x7fa0aa055670 <main.m:9:1> col:1 implicit Darwin.C.stdio|-TypedefDecl 0x7fa0aa0556c0 <line:12:1, col:13> col:13 referenced JH_INT_64 'int'| `-BuiltinType 0x7fa0aa017500 'int'|-FunctionDecl 0x7fa0aa055980 <line:13:1, line:20:1> line:13:5 main 'int (int, const char **)'| |-ParmVarDecl 0x7fa0aa055728 <col:10, col:14> col:14 argc 'int'| |-ParmVarDecl 0x7fa0aa055840 <col:20, col:38> col:33 argv 'const char **':'const char **'| `-CompoundStmt 0x7fa0aa1dc880 <col:41, line:20:1>| |-ObjCAutoreleasePoolStmt 0x7fa0aa1dc838 <line:14:5, line:18:5>| | `-CompoundStmt 0x7fa0aa1dc810 <line:14:22, line:18:5>| | |-DeclStmt 0x7fa0aa055b60 <line:15:9, col:25>| | | `-VarDecl 0x7fa0aa055ae0 <col:9, col:23> col:19 used a 'JH_INT_64':'int' cinit| | | `-IntegerLiteral 0x7fa0aa055b40 <col:23> 'int' 10| | |-DeclStmt 0x7fa0aa1dc5d0 <line:16:9, col:25>| | | `-VarDecl 0x7fa0aa055b88 <col:9, col:23> col:19 used b 'JH_INT_64':'int' cinit| | | `-IntegerLiteral 0x7fa0aa1dc200 <col:23> 'int' 20| | `-CallExpr 0x7fa0aa1dc7b0 <line:17:9, col:31> 'int'| | |-ImplicitCastExpr 0x7fa0aa1dc798 <col:9> 'int (*)(const char *, ...)' <FunctionToPointerDecay>| | | `-DeclRefExpr 0x7fa0aa1dc5e8 <col:9> 'int (const char *, ...)' Function 0x7fa0aa1dc228 'printf' 'int (const char *, ...)'| | |-ImplicitCastExpr 0x7fa0aa1dc7f8 <col:16> 'const char *' <NoOp>| | | `-ImplicitCastExpr 0x7fa0aa1dc7e0 <col:16> 'char *' <ArrayToPointerDecay>| | | `-StringLiteral 0x7fa0aa1dc648 <col:16> 'char [3]' lvalue "%d"| | `-BinaryOperator 0x7fa0aa1dc748 <col:22, line:11:11> 'int' '+'| | |-BinaryOperator 0x7fa0aa1dc708 <line:17:22, col:26> 'int' '+'| | | |-ImplicitCastExpr 0x7fa0aa1dc6d8 <col:22> 'JH_INT_64':'int' <LValueToRValue>| | | | `-DeclRefExpr 0x7fa0aa1dc668 <col:22> 'JH_INT_64':'int' lvalue Var 0x7fa0aa055ae0 'a' 'JH_INT_64':'int'| | | `-ImplicitCastExpr 0x7fa0aa1dc6f0 <col:26> 'JH_INT_64':'int' <LValueToRValue>| | | `-DeclRefExpr 0x7fa0aa1dc6a0 <col:26> 'JH_INT_64':'int' lvalue Var 0x7fa0aa055b88 'b' 'JH_INT_64':'int'| | `-IntegerLiteral 0x7fa0aa1dc728 <line:11:11> 'int' 30| `-ReturnStmt 0x7fa0aa1dc870 <line:19:5, col:12>| `-IntegerLiteral 0x7fa0aa1dc850 <col:12> 'int' 0`-<undeserialized declarations>
在执行语法分析命令的时候，如果有引入 iOS 相关的头文件，则需要加入指定的 SDK 路径来避免执行失败
如下面的命令所示，指定了 iOS 13.2 模拟器的 SDK的路径。
clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.2.sdk -fmodules -fsyntax-only -Xclang -ast-dump main.m
AST 抽象语法树输出之后是一个很明显的树状结构，阅读起来其实并不困难。
|-FunctionDecl 0x7fa0aa055980 <line:13:1, line:20:1> line:13:5 main 'int (int, const char **)'
- 开头的
FunctionDecl表示是一个函数声明节点。后面跟了一个内存地址，就其实是栈空间内的函数的地址。尖括号里面的内容表示是 main 函数的起始范围，从第 13 行的第 1 个字符开始，到第 20 行的第 1 个字符结束。然后后面的line:13:5表示从第 13 行的第 5 个字符开始是函数的参数声明区域。
| |-ParmVarDecl 0x7fa0aa055728 <col:10, col:14> col:14 argc 'int'| |-ParmVarDecl 0x7fa0aa055840 <col:20, col:38> col:33 argv 'const char **':'const char **'
- 这两个节点类型为
ParmVarDecl，表示的是参数节点，其中第一个参数 argc 是 int 类型，第二个参数 argv 是 const char** 类型。
| `-CallExpr 0x7fa0aa1dc7b0 <line:17:9, col:31> 'int'
CallExpr表示的是调用某个函数。后面的int表示调用函数的返回值。这里其实就是源码中printf函数的位置。
| | |-DeclStmt 0x7fa0aa055b60 <line:15:9, col:25>| | | `-VarDecl 0x7fa0aa055ae0 <col:9, col:23> col:19 used a 'JH_INT_64':'int' cinit| | | `-IntegerLiteral 0x7fa0aa055b40 <col:23> 'int' 10| | |-DeclStmt 0x7fa0aa1dc5d0 <line:16:9, col:25>| | | `-VarDecl 0x7fa0aa055b88 <col:9, col:23> col:19 used b 'JH_INT_64':'int' cinit| | | `-IntegerLiteral 0x7fa0aa1dc200 <col:23> 'int' 20
DeclStmt表示的是声明语句节点，这里很容易就能看出声明了两个 int 类型的变量，一个值为 10，一个值为 20。
| | |-ImplicitCastExpr 0x7fa0aa1dc798 <col:9> 'int (*)(const char *, ...)' <FunctionToPointerDecay>| | | `-DeclRefExpr 0x7fa0aa1dc5e8 <col:9> 'int (const char *, ...)' Function 0x7fa0aa1dc228 'printf' 'int (const char *, ...)'| | |-ImplicitCastExpr 0x7fa0aa1dc7f8 <col:16> 'const char *' <NoOp>| | | `-ImplicitCastExpr 0x7fa0aa1dc7e0 <col:16> 'char *' <ArrayToPointerDecay>| | | `-StringLiteral 0x7fa0aa1dc648 <col:16> 'char [3]' lvalue "%d"
ImplicitCastExpr表示隐式转换表达式节点，说明 printf 函数其实前面还有隐式转换的操作：int (*)(const char *, ...)。- 最后一行显然就是 printf 函数的开头位置的
%d，表示接收一个 int 类型的值。
| | `-BinaryOperator 0x7fa0aa1dc748 <col:22, line:11:11> 'int' '+'| | |-BinaryOperator 0x7fa0aa1dc708 <line:17:22, col:26> 'int' '+'| | | |-ImplicitCastExpr 0x7fa0aa1dc6d8 <col:22> 'JH_INT_64':'int' <LValueToRValue>| | | | `-DeclRefExpr 0x7fa0aa1dc668 <col:22> 'JH_INT_64':'int' lvalue Var 0x7fa0aa055ae0 'a' 'JH_INT_64':'int'| | | `-ImplicitCastExpr 0x7fa0aa1dc6f0 <col:26> 'JH_INT_64':'int' <LValueToRValue>| | | `-DeclRefExpr 0x7fa0aa1dc6a0 <col:26> 'JH_INT_64':'int' lvalue Var 0x7fa0aa055b88 'b' 'JH_INT_64':'int'| | `-IntegerLiteral 0x7fa0aa1dc728 <line:11:11> 'int' 30
BinaryOperator表示的是二元运算符。这里阅读的方式应该是先看叶子节点，所以翻译过来就是 (a + b) + 30 的结果作为 printf 函数的入参。
| `-ReturnStmt 0x7fa0aa1dc870 <line:19:5, col:12>| `-IntegerLiteral 0x7fa0aa1dc850 <col:12> 'int' 0
ReturnStmt表示的是函数返回声明节点。显示返回的结果是 int 类型 0。
生成中间代码 IR
完成上面的步骤之后就可以生成中间代码 IR 了，代码生成器会将语法树自顶向下遍历逐步翻译成 LLVM IR。
LLVM IR 有三种表现形式，但本质上是等价的，就好比水可以有气体、液体、固体 3 种形态。
- text ：便于阅读的文本格式，类似于汇编语言，拓展名为 ll。
// 生成 text 格式的 IRclang -S -fobjc-arc -emit-llvm 文件名
- memory ：内存格式
- bitcode ：二进制格式，拓展名为 .bc
// 生成 bitcode 格式的 IRclang -c -fobjc-arc -emit-llvm 文件名
IR 基本语法:
@ 全局标识
% 局部标识
alloca 开辟空间
align 内存对齐
i32 32 bit, 即 4 个字节
store 写入内存
load 读取数据
call 调用函数
ret 返回
下面我们实际测试一下
// main.m#include <stdio.h>int test(int a, int b) {return a + b + 3;}int main(int argc, const char* argv[]) {int a = test(1, 2);printf("%d", a);return 0;}
main.m 文件内容如上，接着我们在终端执行
clang -S -fobjc-arc -emit-llvm main.m
然后会生成一个 main.ll 文件，截取部分代码如下
; Function Attrs: noinline nounwind optnone ssp uwtabledefine i32 @test(i32, i32) #0 {%3 = alloca i32, align 4%4 = alloca i32, align 4store i32 %0, i32* %3, align 4store i32 %1, i32* %4, align 4%5 = load i32, i32* %3, align 4%6 = load i32, i32* %4, align 4%7 = add nsw i32 %5, %6%8 = add nsw i32 %7, 3ret i32 %8}; Function Attrs: noinline optnone ssp uwtabledefine i32 @main(i32, i8**) #1 {%3 = alloca i32, align 4%4 = alloca i32, align 4%5 = alloca i8**, align 8%6 = alloca i32, align 4store i32 0, i32* %3, align 4store i32 %0, i32* %4, align 4store i8** %1, i8*** %5, align 8%7 = call i32 @test(i32 1, i32 2)store i32 %7, i32* %6, align 4%8 = load i32, i32* %6, align 4%9 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([3 x i8], [3 x i8]* @.str, i32 0, i32 0), i32 %8)ret i32 0}
我们先看 main 方法，可以看到 main 方法里面有两处 call 的使用，分别对应了 main.m 中对 test() 方法和 print 方法的调用。接着我们看 test 方法在 IR 中的表现：
// IRdefine i32 @test(i32, i32)// main.mint test(int a, int b)
- 这一行等价于
int test(int a, int b)。第一个 i32 表示函数的返回值，第二个和第三个 i32 表示函数参数。这里其实有两个隐藏的标识 %0 和 %1 ，分别表示参数 a 和 b。
%3 = alloca i32, align 4%4 = alloca i32, align 4
- 分配 4 个字节内存空间，并以 4 字节对齐，返回给 %3 标识
- 分配 4 个字节内存空间，并以 4 字节对齐，返回给 %4 标识
store i32 %0, i32* %3, align 4store i32 %1, i32* %4, align 4
- 将 %0 标识中内容取出，存入 %3 标识的内存空间，并以 4 字节对齐
- 将 %1 标识中内容取出，存入 %4 标识的内存空间，并以 4 字节对齐
%5 = load i32, i32* %3, align 4%6 = load i32, i32* %4, align 4
- 将 %3 标识中内容取出，存入 %5 标识的内存空间，并以 4 字节对齐
- 将 %4 标识中内容取出，存入 %6 标识的内存空间，并以 4 字节对齐
%7 = add nsw i32 %5, %6%8 = add nsw i32 %7, 3
- 将 %5 和 %6 标识相加，结果赋值给 %7 标识
- 将 %7 标识和 3 相加，结果赋值给 %8 标识
ret i32 %8
- 返回 %8 标识的内容
上面这一系列操作其实等价于 main.m 中 test 函数的内容: return a + b + 3;
但是在 IR 中间代码中，这一行代码被转换成了更多的步骤，其实，这里是因为执行生成 IR 代码的命令默认是没有开启优化的，我们可以在 XCode 中查看在 Debug 和 Release 模式下对应的优化级别:
优化级别从低到高分为:
- None: Debug 模式的默认选项，没有优化。标识符为
-O0。 - Fast: 标识符为
-O, O1。 - Faster: 标识符为
-O2。 - Fastest: 标识符为
-O3。 - Fastest, Smallest: 标识符为
-Os。 - Fastest, Aggressive Optimizations: 标识符为
-Ofast。 - Smallest, Aggressive Size Optimizations: 标识符为
-Oz。
比如，我们采取 Fastest, Smallest 优化策略，在终端可以这样输入
clang -Os -S -fobjc-arc -emit-llvm main.m -o main1.ll
截取 main1.ll 部分内容如下
; Function Attrs: norecurse nounwind optsize readnone ssp uwtabledefine i32 @test(i32, i32) local_unnamed_addr #0 {%3 = add i32 %0, 3%4 = add i32 %3, %1ret i32 %4}; Function Attrs: nounwind optsize ssp uwtabledefine i32 @main(i32, i8** nocapture readnone) local_unnamed_addr #1 {%3 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([3 x i8], [3 x i8]* @.str, i64 0, i64 0), i32 6) #3, !clang.arc.no_objc_arc_exceptions !9ret i32 0}
可以看到 IR 的代码行数被大大压缩了。并且在 main 方法里面，直接算出了 test 函数的执行结果为 6，而省略了对 test 函数的调用。
生成汇编代码
通过最终的 bc 或者 ll 中间代码生成汇编代码
// ll 生成汇编clang -S -fobjc-arc main.ll -o main.s// bc 生成汇编clang -S -fobjc-arc main.bc -o main.s
生成汇编代码也可以采用优化策略
clang -Os -S -fobjc-arc 中间代码IR -o 汇编源文件
我们测试一下
clang -Os -S -fobjc-arc main.ll -o main.s
输出的汇编源文件 main.s 内容如下:
.section __TEXT,__text,regular,pure_instructions.build_version macos, 10, 15 sdk_version 10, 15.globl _test ## -- Begin function test.p2align 4, 0x90_test: ## @test.cfi_startproc## %bb.0:pushq %rbp.cfi_def_cfa_offset 16.cfi_offset %rbp, -16movq %rsp, %rbp.cfi_def_cfa_register %rbpmovl %edi, -4(%rbp)movl %esi, -8(%rbp)movl -4(%rbp), %esiaddl -8(%rbp), %esiaddl $3, %esimovl %esi, %eaxpopq %rbpretq.cfi_endproc## -- End function.globl _main ## -- Begin function main.p2align 4, 0x90_main: ## @main.cfi_startproc## %bb.0:pushq %rbp.cfi_def_cfa_offset 16.cfi_offset %rbp, -16movq %rsp, %rbp.cfi_def_cfa_register %rbpsubq $32, %rspmovl $0, -4(%rbp)movl %edi, -8(%rbp)movq %rsi, -16(%rbp)movl $1, %edimovl $2, %esicallq _testmovl %eax, -20(%rbp)movl -20(%rbp), %esileaq L_.str(%rip), %rdimovb $0, %alcallq _printfxorl %esi, %esimovl %eax, -24(%rbp) ## 4-byte Spillmovl %esi, %eaxaddq $32, %rsppopq %rbpretq.cfi_endproc## -- End function.section __TEXT,__cstring,cstring_literalsL_.str: ## @.str.asciz "%d".section __DATA,__objc_imageinfo,regular,no_dead_stripL_OBJC_IMAGE_INFO:.long 0.long 64.subsections_via_symbols
生成目标文件
目标文件的生成，是汇编器以汇编代码作为输入，将汇编代码转换为机器代码, 最后输出目标文件。命令如下:
clang -fmodules -c 汇编源文件 -o 目标文件
我们测试一下
clang -fmodules -c main.s -o main.o
生成完目标文件之后，我们可以通过 nm 命令来查看符号情况
nm -nm main.o// 输出(undefined) external _printf0000000000000000 (__TEXT,__text) external _test0000000000000020 (__TEXT,__text) external _main
_prinf 是一个 undefined external 符号，其中 undefined 表示在当前文件暂时找不到符号 _prinf，而 external 表示这个符号是外部可以访问的。
生成可执行文件
链接器把编译产生的 .o 文件和库文件(动态库 .dylib, 静态库 .a)文件链接起来，生成了一个 Mach-O 可执行文件。
命令如下
clang 目标文件名 -o 可执行文件名
我们测试一下
clang main.o -o main
接着查看可执行文件中的符号情况
xcrun nm -nm main(undefined) external _printf (from libSystem)(undefined) external dyld_stub_binder (from libSystem)0000000100000000 (__TEXT,__text) [referenced dynamically] external __mh_execute_header0000000100000f20 (__TEXT,__text) external _test0000000100000f40 (__TEXT,__text) external _main0000000100002008 (__DATA,__data) non-external __dyld_private
可以看到 printf 函数的符号是从 libSystem 库中加载而来，说明系统函数是在运行时通过 dyld 去做符号绑定的。
编译 LLVM 工程
LLVM 下载
由于国内的网络限制，最好借助下面的镜像下载 LLVM 的源码
- 下载 LLVM 项目
git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/llvm.git
- 在 LLVM 的 tools 目录下下载 Clang
cd llvm/toolsgit clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/clang.git
- 在 LLVM 的 projects目录下下载 compiler-rt, libcxx, libcxxabi
cd ../projectsgit clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/compiler-rt.gitgit clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/libcxx.gitgit clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/libcxxabi.git
- 在 Clang 的 tools 下安装 extra 工具
cd ../tools/clang/toolsgit clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/clang-tools-extra.git
LLVM 编译
由于最新的 LLVM 只支持 cmake 编译，我们还需要安装 cmake
安装 cmake
- 查看 brew 是否安装了 cmake，如果已经安装跳过这一步骤
brew list
- 通过 brew 安装 cmake
brew install cmake
通过 Xcode 编译 LLVM
- cmake 编译成 Xcode 项目
mkdir build_xcodecd build_codecmake -G Xcode ../llvm
- 使用 Xcode 编译 Clang
- 选择自动创建 Schemes
- 编译，选择 ALL_BUILD Scheme 进行编译，预计花费 1 个多小时
- 选择自动创建 Schemes
Clang 插件初探
编译完成后，我们可以基于 Clang 来定制属于我们自己的插件。
Clang 一共提供了三种不同的方式来编写:
- LibClang: 稳定的高级C语言抽象接口
优点：1.可以使用 C++ 之外的语言与clang交互.2.有稳定的交互接口 & 向后兼容.3.提供强大的高级抽象 例如通过cursor 迭代AST，&不用学习Clang‘s AST 详细知识.缺点：不能完全控制clang AST
ps：官方提供 c&python 形式API，这里有一个OC形式的 Clangkit
- Clang Plugins：Clang 插件允许你在AST上添加运行其他操作作为编译的一部分。插件是由编译器在运行时加载的动态库，它们很容易集成到构建环境中。
使用Clang插件：1.如果任何依赖关系发生变化，则需要您的工具重新运行2.希望您的工具能够制作或打破构建3.需要完全控制Clang AST不使用Clang插件：1.想要在构建环境之外运行工具2.想要完全控制Clang的设置，包括内存虚拟文件的映射3.需要在项目中运行特定的文件子集，而这些文件与触发重建的任何更改无关
ps：当你需要针对您的项目的特殊格式的警告或错误，或者从一个编译步骤创建额外的构建工件时，clang plugins 是你的不二之选。
- LibTooling 是一个 C++ 接口，旨在编写独立工具，以及集成到运行clang工具的服务中。
使用LibTooling：1.希望独立于构建系统，在单个文件或特定文件子集上运行工具2.想要完全控制Clang AST3.想与Clang插件分享代码不使用LibTooling：1.想要作为由依赖性更改触发的构建的一部分运行2.想要一个稳定的接口，以便在AST API更改时不需要更改代码3.希望使用像cursor这样的高级抽象4.不想用C ++编写你的工具
ps：当你需要写一个简单的语法检查器或者一个重构工具时，选择libTooling
我们现在的需求是能够在编译时检查属性标识符应该设置 copy 但是没有设置的情况，然后给出相应的警告提示信息。
所以我们的最佳方案就是 clang plugin, 我们看下它是如何执行的：
具体是在动态库装载进来后，可以拿到我们自定义的 pluginAction(FrontendAction 的子类)。
然后在 CompileInstance 初始化之后，依次调用 pluginAction 的几个成员函数（BeginSourceFile、Excute、EndSourceFile）。
其中 CreateConsumer 创建我们自定义的 consumer 来获取语法树信息，执行ExecuteAction 函数进入 ParseAST 分析流程，调用我们自定义的 ASTConsumer 去handle，通过 RecursiveASTVisitor 或 ASTMatcher 来匹配想检查操作的AST Notes。
如果不符合规范的话，创建一个diagnosis 来警告或报错，并且可以创建一个 FixHint 来提供修复能力。期间通过 ASTContext 及其关联的 SourceManager 获取源码位置&全局标识符等信息。
上述的 ParseAST 阶段，推荐使用 ASTMatcher，可以简单、精准、高效的匹配到AST Notes。
创建插件
- 在
/llvm/tools/clang/tools目下新建插件的文件夹
- 修改
/llvm/tools/clang/tools目下的CMakeLists.txt文件，加入一行add_clang_subdirectory(插件文件夹名称)
- 在 JHPlugin 目录下新建一个名为 JHPulgin.cpp 的源文件，再新建一个 CMakeLists.txt 的文本文件。
CMakeLists.txt 文件中写入如下的内容
add_llvm_library( JHPlugin MODULE BUILDTREE_ONLYJHPlugin.cpp)
- 使用 cmake 重新生成 Xcode 项目，在 build_xcode 中执行
cmake -G Xcode ../llvm - 最后可以在 LLVM 的 Xcode 项目中可以看到 Loadable modules 目录下有自己的 Plugin 目录了。
编写插件
1.自定义一个继承于 PluginASTAction 的 Action
// 继承 PluginASTActionclass JHASTAction : public PluginASTAction {public:unique_ptr<ASTConsumer> CreateASTConsumer(CompilerInstance &Compiler, StringRef InFile);bool ParseArgs(const CompilerInstance &CI, const std::vector<std::string> &args);};
2.注册插件
//注册插件static FrontendPluginRegistry::Add<JHPlugin::JHASTAction>X("JHPlugin", "This is the description of the plugin");
2.自定义一个继承于 ASTConsumer 的 consumer
// 自定义 ASTConsumerclass JHConsumer : public ASTConsumer {}
ASTConsumer 类型是专门用来解析 AST 语法树的节点的抽象类，通过子类化这个抽象类，我们可以重写 ASTConsumer 类提供的一系列解析节点的方法:
// HandleTopLevelDecl - Handle the specified top-level declaration./// This iscalled by the parser to process every top-level Decl*.////// \returns true to continue parsing, or false to abort parsing.// 解析一个顶级的声明节点virtual bool HandleTopLevelDecl(DeclGroupRef D);/// HandleTranslationUnit - This method is called when the ASTs for entire/// translation unit have been parsed.\// 解析完整个文件后被调用virtual void HandleTranslationUnit(ASTContext &Ctx) {}
我们在 JHConsumer 里面添加下面两个方法:
// 解析顶级节点bool HandleTopLevelDecl(DeclGroupRef D) {cout << "正在解析..." << endl;return true;}// 解析完整个文件后被调用void HandleTranslationUnit(ASTContext &Ctx) {cout << "文件解析完毕!" << endl;matcher.matchAST(Ctx);}
然后我们编译一下当前的插件，接着我们用编译好的 clang 和 JHPlugin 来测试一下效果。我们在桌面新建一个 main.m 文件，内容如下:
int test(int a, int b) {return a + b;}int test2(int a, int b, int c) {return a + b + c;}int main() {test(1, 2);test2(1, 2, 3);return 0;}
接着在终端中执行如下的命令:
/Users/leejunhui/Documents/iOS/OpenSourceApple/LLVM源码/build_xcode/Debug/bin/clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.2.sdk -Xclang -load -Xclang /Users/leejunhui/Documents/iOS/OpenSourceApple/LLVM源码/build_xcode/Debug/lib/JHPlugin.dylib -Xclang -add-plugin -Xclang JHPlugin -c main.m
这段命令拆分一下:
自己编译的 clang 文件路径 -isysroot iOS的SDK路径 -Xclang -load Xclang 插件的dylib路径 -Xclang -add-plugin -Xclang 插件名称 -c 源文件
最后输出如下:
正在解析...正在解析...正在解析...文件解析完毕!
说明 main.m 中的三个顶级节点以及整个文件都解析完成。
3.最终代码
#include <iostream>#include "clang/AST/AST.h"#include "clang/AST/DeclObjC.h"#include "clang/AST/ASTConsumer.h"#include "clang/ASTMatchers/ASTMatchers.h"#include "clang/Frontend/CompilerInstance.h"#include "clang/ASTMatchers/ASTMatchFinder.h"#include "clang/Frontend/FrontendPluginRegistry.h"using namespace clang;using namespace std;using namespace llvm;using namespace clang::ast_matchers;namespace JHPlugin {class JHMatchCallback: public MatchFinder::MatchCallback {private:CompilerInstance &CI;//判断是否是自己的文件bool isUserSourceCode(const string filename) {if (filename.empty()) return false;// 非Xcode中的源码都认为是用户源码if (filename.find("/Applications/Xcode.app/") == 0) return false;return true;}//判断是否应该用copy修饰。bool isShouldUseCopy(const string typeStr) {if (typeStr.find("NSString") != string::npos ||typeStr.find("NSArray") != string::npos ||typeStr.find("NSDictionary") != string::npos/*...*/) {return true;}return false;}public:JHMatchCallback(CompilerInstance &CI):CI(CI){}void run(const MatchFinder::MatchResult &Result){//通过结果获取到节点。const ObjCPropertyDecl *propertyDecl = Result.Nodes.getNodeAs<ObjCPropertyDecl>("objcPropertyDecl");//获取文件名称string filename = CI.getSourceManager().getFilename(propertyDecl->getSourceRange().getBegin()).str();if (propertyDecl && isUserSourceCode(filename)) {//如果节点有值,并且是用户文件//拿到属性的类型string typeStr = propertyDecl->getType().getAsString();//拿到节点的描述信息ObjCPropertyDecl::PropertyAttributeKind attrKind = propertyDecl->getPropertyAttributes();//判断是不是应该用Copyif (isShouldUseCopy(typeStr) && !(attrKind & ObjCPropertyDecl::OBJC_PR_copy)) {cout<<typeStr<<"应该用copy修饰而没用Copy，发出警告！"<<endl;//诊断引擎DiagnosticsEngine &diag = CI.getDiagnostics();//Report 报告diag.Report(propertyDecl->getBeginLoc(),diag.getCustomDiagID(DiagnosticsEngine::Warning, "%0这个地方推荐用Copy"))<<typeStr;}}}};//自定义的JHConsumerclass JHConsumer: public ASTConsumer {private:MatchFinder matcher;JHMatchCallback callback;public:JHConsumer(CompilerInstance &CI):callback(CI){//添加一个MatchFinder去匹objcPropertyDecl节点//回调在JHMatchCallback的run方法里面。matcher.addMatcher(objcPropertyDecl().bind("objcPropertyDecl"),&callback);}// 在整个文件都解析完后被调用void HandleTranslationUnit(ASTContext &context) {cout<<"解析完毕了！"<<endl;matcher.matchAST(context);}};//继承PluginASTAction实现我们自定义的 Actionclass JHASTAction: public PluginASTAction {public:bool ParseArgs(const CompilerInstance &CI,const vector<string> &arg){return true;}unique_ptr <ASTConsumer> CreateASTConsumer(CompilerInstance &CI, StringRef InFile) {return unique_ptr <JHConsumer> (new JHConsumer(CI));}};}//注册插件static FrontendPluginRegistry::Add<JHPlugin::JHASTAction> X("JHPlugin", "This is the description of the plugin");
我们在 ViewController 里面声明如下四个属性：
@interface ViewController ()@property (nonatomic, strong) NSArray *arr;@property (nonatomic, strong) NSString *str;@property (nonatomic, copy) NSArray *arr1;@property (nonatomic, copy) NSString *str1;@end
然后运行一下:
/Users/leejunhui/Documents/iOS/OpenSourceApple/LLVM源码/build_xcode/Debug/bin/clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.2.sdk -Xclang -load -Xclang /Users/leejunhui/Documents/iOS/OpenSourceApple/LLVM源码/build_xcode/Debug/lib/JHPlugin.dylib -Xclang -add-plugin -Xclang JHPlugin -c ViewController.m
输出如下：
解析完毕了！NSArray *应该用copy修饰而没用Copy，发出警告！ViewController.m:12:1: warning: NSArray *这个地方推荐用Copy@property (nonatomic, strong) NSArray *arr;^NSString *应该用copy修饰而没用Copy，发出警告！ViewController.m:13:1: warning: NSString *这个地方推荐用Copy@property (nonatomic, strong) NSString *str;^2 warnings generated.
可以看到最后由两个应该使用 copy 修饰符的属性因为没有使用 copy 而被监测到并且报了警告。
插件集成到 Xcode
我们上面的方式只能在终端查看插件的执行结果，但是更理想的应该是集成到 Xcode 内部。
我们打开测试项目，在 Build Settings -> Other C Flags 里面添加如下内容:
-Xclang -load Xclang (.dylib)动态库路径 -Xclang -add-plugin -Xclang 插件名
此时，我们执行 Command + B 编译一下项目会有如下的报错信息
解决方案是添加两个设置，如下所示
- CC 对应的是自己编译的 clang 的绝对路径
- CXX 对应的是自己编译的 clang++ 的绝对路径
接着再修改一个设置，如下所示
最后，我们 Command + B 再次编译，注意，这次编译时间会花费得比较久，因为 Xcode 要加载我们自己编译的 clang，等待加载完成后，我们可以看到如下的提示
总结
参考资料
若有收获，就点个赞吧
0 人点赞
