- 广义 LLVM 架构包括编译前端 + 中间优化 + 编译后端；
- 狭隘 LLVM 指的就是中间优化 + 编译后端；
- Clang 属于广义 LLVM 中的编译前端，针对的是 C/C++/OC，而 Swift 的编译前端是 Swift；
- 编译前端的工作就是将源码转换成 LLVM 架构中的 IR（通用中间代码）；
- 编译后端主要面向硬件和中间代码，工作主要包括两部分：针对不同的 CPU 对中间代码进行优化、将中间代码根据不同的硬件转化成汇编代码，进而转化成二进制的机器码；
- 编译后端的输出是跨平台的，也就是说汇编代码生成的机器码只和硬件相关，和平台无关，比如都是 X86_64 的机器码，无论是在 windows 上还是在 MacOS 上都可以被识别；
- 但是，跨平台不仅需要硬件支持，还需要软件层面支持；
- 硬件层面的支持本质就是中间代码转汇编进而转成平台相关的机器码，所以一个编译后端应用程序对应着一个平台；
- 软件层面指的就是操作系统，现代计算机架构由于操作系统的存在，隔绝了用户（程序员）对硬件的直接访问。因此，不同的操作系统自然就形成了不同的硬件相关的规则，主要是内存、硬件 Api 等的不同；
- 跨平台软件层面就是需要针对不同的操作系统，按照既定的可执行文件的规则来组织代码和数据。可执行文件一旦按规则形成，后续的执行就是操作系统的事了，比如 iOS 中的 dyld 负责代码的加载、虚拟内存的映射、动态链接、重定位等等一系列操作。这在 windows 中也有和 dyld 类似的角色；
- 对于中间代码而言，也可以使跨平台相关的。虽然中间代码是通用的，但是其中的优化可能是针对不同的硬件进行的优化，也就是说会有很多 if else。当 LLVM 需要支持一种新的硬件（新的 CPU 架构），除了新增一个编译后端之外，如果对这个硬件有优化操作，那么中间优化阶段，需要使用中间代码新增 if else；
总结：
- 跨平台包含三要素：编译前端、编译后端、操作系统；
另外，还需要说一个 LLVM 的根本优势：
- LLVM 相对于 gcc 的根本优势在于解耦。
举个例子，假如说新诞生了一种语言： OC
- 那么首先就需要一个编译前端来将 OC 转化成中间代码，也就是 Clang 的诞生；
- 假如最初阶段，arm64 架构的 iPhone CPU 还没有诞生， OC 只想支持 x86_64 这一种硬件，也就是跑在旧版本的 Mac 上。如果 LLVM 没有这种 x86_64 架构的支持，那么就需要新增一个编译后端；
- 但是实际情况是 C/C++ 语言需要跑在 x86_64 上，可能在一开始 LLVM 就已经实现了针对 x86_64 的编译后端了。大白话就是中间代码可以直接转化成 x86_64 的汇编进而转化成 x86_64 对应的二进制机器码，这样如果 OC 需要支持 X86_64 就不需要重新实现一套了。能够做到这样的本质是中间代码是通用的，而编译后端的实现是面向 IR + 硬件的；
- OC 有了 x86_64 的硬件支持，还需要软件层面上的支持，比如 OC 一开始只想跑在 MacOS 系统上，那么就需要按照 MacOS 中的可执行文件的规则，对二进制代码和数据进行组织，这也就是 Mach-O 文件诞生的理论基础，而这个工作不是在编译后端完成的，编译后端只生成机器码，可执行文件的生成需要 Clang 自己去组织；
- 其实，组织完成之后还包括运行，macOS 上采用的 dyld 来链接。如果按照 Mach-O 可执行文件的标准来组织数据了，那么就并不需要做额外的工作了，因为在生成可执行文件时，就已经：组织好了代码（_TEXT）和数据（_DATA），并且组织好了链接信息（_LINKEDIT） ，并且进行了签名（SIGNATURE）等一系列操作；
- 上述过程在 Windows 上就完全不一样，windows 上的可执行文件时 .exe，也就是说需要按照 Windows 中可执行文件的标准来组织代码、数据等，这也是 OC 不跨平台的根本。也就是说，OC 跨平台其实在编译前端、编译后端都是支持的，只不过没有针对操作系统层面实现不同的可执行程序标准；
- 假设后面出来一种 arm64 的全新架构，只需要增加一个编译后端，那么 C/C++/OC 都可以直接通过这一个编译后端生成 arm64 架构下的机器码；
上述过程中，因为 gcc 是全链路耦合的，如果是 gcc 来实现 OC/C/C++，那么就需要：
- OC + 中间代码 + x86_64；
- OC + 中间代码 + arm64；
- C + 中间代码 + x86_64；
- C + 中间代码 + arm64；
- C++ + 中间代码 + x86_64；
- C++ + 中间代码 + arm64；
写代码的时候，如果为了图省事，经常复制粘贴相同代码到各种地方复用，恐怕会有这种似曾相识的恐怖感吧......
对比 LLVM：
- 只需要一个 x86_64 和 arm64 的编译后端；
- 如果新的语言只需要支持这两种架构，那么只需要实现编译前端（源代码的解析）和操作系统层面上的可执行文件的实现；
- 同理，如果现存的 n 种语言需要支持一种新出的硬件（如 CPU 架构），只需要实现一个编译后端，所有的编译前端、可执行文件的组织逻辑，这些都可以复用，甚至完全不需要改变；
这就是耦合的最大弊端，而 LLVM 中解耦靠的就是 IR，通用中间代码；
解耦的关键在于：规则制定、实现和维护，实现的本质就是按规则进行封装。
这个道理应用到组件化解耦中，也是一样。组件化解耦首先需要制定依赖规则，然后在开发过程中去遵守，并且定期 Review。Review 的目的是防止过多的不符规则的代码突破需要重构的临界点。一旦突破临界点，就只能花更多、更整块的时间去做重构了。
而这种整块的时间，一般的迭代开发中是挤不出来的，所以这种情况一旦出现，可能就是毁灭性的打击：
- 进，各种莫名的问题层出不穷，需要耗费大量时间去定位和解决版本无关的问题。
- 退，如果不是业务的商业模式确定并且完成扩张，进入了稳定，谁会给你这么成片的时间去重构？而如果是快速迭代期，竞争对手追着抢市场，新版本还要不要上？
