LLVM(1)

2024-02-13 00:04| 来源: 网络整理| 查看: 265

1、引言

作为一名iOS开发，很难不从各种渠道听说关于LLVM的消息，如早年编译器从GCC过度到LLVM-GCC，然后由于GCC的开源协议改变，让Apple彻底抛弃GCC转而投向目前正在使用的Clang。比如之前微信团队分享的编译优化。再如之后业内影响颇大的字节团队分享的二进制重排提及的插装所知的也是clang。在安全方面，对LLVM pass的开发也是主力军等等。。。

所以适当的了解LLVM对自己的知识广度是有非常大的帮助的，最少在读一篇有深度的文章的时候，不至于摸不到门槛。

2、什么是LLVM，什么是Clang

LLVM 最早是底层虚拟机（Low Level Virtual Machine）的缩写，但由于项目发展过快，底层虚拟机已经不足以介绍项目本身，而它已经发展成为一个包含前端，优化器和后端的完整编译框架，并且全称就叫LLVM，并非任何英文的简称了。其主要由C++编写而成。

一、什么是LLVM 传统编译器架构

传统编译器架构（如GCC）将前端，优化器，后端耦合在一起，优化难度大，对多架构兼容的也不太友好，需要做大量重复的工作。

传统的编译器架构.png LLVM架构

LLVM架构三端（前端，优化器，后端）清晰 1、前端面向源码，将源码转化为同样的LLVM Intermediate Representation (LLVM IR)， 2、优化器则针对LLVM IR进行一系列优化，如：无用代码消除，内存优化，甚至是代码混淆等等。。。 3、后端则将IR转化为对应的机器码。

LLVM架构.png

从两种架构的设计可以看得出来，LLVM最大的优势就在于三端分离，所以如果我们想编写一门独立的语言，只需要编写相应的前端就可以兼容各大终端设备。如果以后多了一种终端设备，我们也只需要编写一次后端，就可以兼容各大语言。

二、什么是Clang

Clang是LLVM项目的一个子项目，基于LLVM架构的C/C++/Objective-C编译器前端（Swift的前端是Swift）。

Apple早年从GCC切换到LLVM的时候，开始用的是基于GCC库写的一套LLVM前端，但由于Apple对代码优化的要求更高，而GCC官方又迟迟不肯对针对性的更新，所以衍生出GCC的一套分支LLVM-GCC，由Apple自己维护，导致Apple使用的GCC版本远低于官方版本，最后由于GCC的开源协议改变，让Apple彻底抛弃GCC转而投向自研的Clang。

相比于GCC，Clang具有如下优点： · 编译速度快:在某些平台上，Clang的编译速度显著的快过GCC(Debug模式下编译OC速度比GGC快3倍) · 占用内存小:Clang生成的AST所占用的内存是GCC的五分之一左右 · 模块化设计:Clang采用基于库的模块化设计，易于 IDE 集成及其他用途的重用 · 诊断信息可读性强:在编译过程中，Clang 创建并保留了大量详细的元数据 (metadata)，有利于调试和错误报告 · 设计清晰简单，容易理解，易于扩展增强

3、编译过程 ① 下载

找到一个自己方便的目录，直接在github上下载（耗时根据网络情况而定，包括git文件总大小大概3G）:

image.png > mkdir llvm_all && cd llvm_all > git clone https://github.com/llvm/llvm-project.git

完成后你将会看到这样一个目录：

image.png

目前我们只需要关注其中两个文件clang和llvm分别是clang的源码和llvm的源码

② 编译 cmake -S llvm -B build -G [options]

官方介绍了4种编译工具：

Ninja --- for generating Ninja build files. Most llvm developers use Ninja. Unix Makefiles --- for generating make-compatible parallel makefiles. Visual Studio --- for generating Visual Studio projects and solutions. Xcode --- for generating Xcode projects.

官方推荐使用Ninja编译，因为其速度最快，笔者也亲试，整个过程只需20分钟左右即可完成。但作为一名iOS开发，还是习惯使用Xcode编译，毕竟界面看起来亲切，而且可在之后我们编写插件的或者IR Pass的时候也能或得良好的代码提示，缺点就是慢一点。笔者使用Xcode编译花了40分钟左右，这根据个人电脑配置而定，配置稍微差一点，一个小时多也是正常的。

另外还有一些可选参数：

-DLLVM_ENABLE_PROJECTS='...' --- 可选一些LLVM的子项目共同编译，如 clang, clang-tools-extra, libcxx, libcxxabi, libunwind, lldb, compiler-rt, lld, polly, 或者 cross-project-tests 例如，如果要编译包括 Clang, libcxx, 和 libcxxabi 的LLVM, 可以增加 -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi" -DCMAKE_INSTALL_PREFIX=directory --- 指定一个绝对地址来存放编译的结果，默认存放在/usr/local. -DCMAKE_BUILD_TYPE=type --- 这是编译的类型，如Debug, Release, RelWithDebInfo, 和 MinSizeRel. 默认的是Debug. -DLLVM_ENABLE_ASSERTIONS=On --- 在启用断言检查的情况下编译（对于Debug构建，默认值为Yes，对于所有其他构建类型，默认值为No）. Ninja编译

所以如果需要使用Ninja编译的话命令，需要先创建Ninja模板（大概5分钟），然后再编译：

// 创建ninja的目录，并且进入其中 mkdir llvm_ninja && cd llvm_ninja // 指定llvm源码目录，新建build目录，创建ninja模板，增加子项目clang，并且模板之后编译的结果放在llvm_release目录下 cmake -S ../llvm-project/llvm -B build -G Ninja -DLLVM_ENABLE_PROJECTS="clang" -DCMAKE_INSTALL_PREFIX=/Volumes/ExDisk/LLVM/llvm_all/llvm_release image.png

从上图中可以看到，我们增加的clang参与了编译，而clang-tools-extra没有参与编译。

如果你看到下面这样的结果，那么恭喜ninja模板已经建好

image.png image.png

然后进入模板目录，输入命令开始编译

cd build ninja && ninja install image.png

完成后可以在指定的release目录下看到所有的命令了

image.png Xcode编译

同样的先在对应的目录下，生成Xcode模板，但xcode就不指定对应的release目录了，因为做iOS开发的应该都知道，Xcode的编译产物有对应的product文件（大概10分钟）

mkdir llvm_xcode && cd llvm_xcode cmake -S ../llvm-project/llvm -B build -G Xcode -DLLVM_ENABLE_PROJECTS="clang" image.png

同样，结束后可以看到这样的目录

image.png image.png

打开LLVM工程，回到了熟悉的画面

image.png

选中Automatically Creat Schemes后，在选择al_build，cmd+b即可开始编译（大概40分钟）。

image.png

在熟悉的地方可以看到对应的编译产物

image.png

在同级目录下，可以看到对应的命令行工具，比如我们下章需要讲到的clang。

image.png 4、总结

为什么编译单独拿出来？LLVM就想一个含羞的蒙面女子，大多数人都是只可远观，而不敢亵玩，其实蒙面女子本身也是及其渴望有个勇士来揭开其面纱，而编译自己的LLVM就像是这么一步，只要自己迈出了这一步，那么就是个崭新的世界。

下一章，就会开始聊一些好玩的事情，比如如何编译自己的插件，如何开发自己混淆器，如何开发自己的一门开发语言。

参考

1、 GCC，LLVM，Clang编译器对比 2、微信团队分享的编译优化 3、深入剖析 iOS 编译 Clang LLVM 4、 LLVM Github地址

【本文地址】

LLVM(1)

LLVM(1)

今日新闻

推荐新闻