GCC 和 LLVM 各自的优缺点
本文来自于我关于 ARM 汇编指令系列文章。欢迎阅读、点评与交流~
1、GCC是什么？
2、LLVM是什么？
3、GCC 和 LLVM 各自的优缺点
GCC 和 LLVM 是现代编译工具链的两大支柱，它们之间的竞争极大地推动了整个领域的发展。以下是它们各自优缺点的详细对比：
GCC
优点：
成熟稳定，历史悠久
- 始于1987年，是开源运动的旗舰项目，经过数十年的工业级测试和打磨。
- 在嵌入式、超算、服务器等关键领域拥有无可比拟的稳定性和可靠性记录。
语言支持广泛且标准兼容性极佳
- 支持C, C++, Fortran, Ada, Go, D等语言，并且对语言标准（如C++）的遵循通常比早期的LLVM更严格、更及时。
- 常被用作其他编译器进行标准符合性测试的参考。
目标平台支持无与伦比
- 支持最多的CPU架构和操作系统（超过50种后端），尤其是在一些小众、嵌入式或遗留平台上，GCC往往是唯一可用的高质量编译器。
运行时库无许可证风险
- 使用GPLv3许可证，其运行时库（如libgcc, libstdc++）的版权归自由软件基金会。这意味着使用GCC编译的专有软件无需担心其运行时库的版权问题（因为GCC的运行时库有明确的“GCC运行时库例外”条款）。
一体化设计，整体优化能力强
- 从源代码到机器码的整个流程在同一个进程内完成，理论上可以进行更深层次的整体优化。
缺点：
架构相对陈旧
- 代码历史悠久，模块化程度较低，前后端耦合紧密。这使得添加新语言或新CPU后端非常困难，学习曲线陡峭。
- 对现代IDE/工具链的友好度较差。
开发流程与生态
- 开发决策相对集中，社区贡献流程不如LLVM开放和敏捷。
- 插件系统和外部工具接口较弱。
性能与编译速度
- 在历史上，其生成的代码优化能力在某些领域（尤其是x86架构上）曾被LLVM的Clang超越。虽然差距已大幅缩小，但在一些微架构的优化上，双方互有胜负。
- 编译速度通常比LLVM/Clang慢一些。
许可证的“传染性”
- GPLv3许可证要求对GCC本身的修改必须开源。这使得苹果等公司不愿使用或贡献，从而催生了LLVM。
LLVM
优点：
现代化、模块化、库化的设计
- 这是LLVM最核心的优势。整个编译器被设计为一组可复用的库（
libLLVMCore,libLLVMAnalysis等）。 - 极大降低了开发新编译器、新工具、新优化Pass或新后端的门槛。Rust、Swift等新语言选择LLVM作为后端，正是看中了这一点。
- 这是LLVM最核心的优势。整个编译器被设计为一组可复用的库（
极其活跃和开放的生态
- 采用相对宽松的Apache 2.0或MIT许可证，吸引了苹果、谷歌、英特尔、NVIDIA等商业巨头的巨额投入和贡献。
- 开发流程透明，社区充满活力，创新速度快。
卓越的工具链和IDE集成
- Clang作为前端，提供了出色的编译速度、低内存占用和清晰的错误/警告信息。
- 天生支持精准的源代码级工具，如：
clang-format（格式化）、clang-tidy（静态分析）、clangd（语言服务器）、优秀的代码补全和重构。
强大的中间表示与优化框架
- LLVM IR设计精良，是优化和静态分析的绝佳载体。
- 优化器高度可配置，易于添加自定义Pass。
对新兴领域的引领
- 在模糊测试（libFuzzer）、源码级消毒剂（ASan, UBSan, TSan）、JIT编译（用于解释器和运行时优化）、异构计算等方面是事实上的标准或领导者。
缺点：
平台支持范围相对较窄
- 虽然支持所有主流平台，但对非常小众或遗留的CPU架构的支持远不如GCC完善。
许可证的复杂性与风险
- LLVM核心使用Apache 2.0，但某些子项目（如lldb）使用不同许可证。
- 最大的争议在于其C++标准库libc++：它没有类似GCC的“运行时库例外”。这意味着，如果一个专有软件使用了libc++的某些特定部分，可能需要开源整个软件（取决于律师的解释）。这使得许多商业公司（尤其是嵌入式领域）对libc++的使用非常谨慎。
成熟度与稳定性
- 在某些极其复杂的模板代码或边缘情况下的C++标准符合性上，Clang历史上曾略逊于GCC。
- 对新架构后端的支持，其代码生成质量在初期可能不如GCC稳定。
碎片化风险
- 模块化设计导致不同项目（如不同语言的编译器）可以使用不同版本的LLVM库，有时会带来兼容性问题。
选择建议
选择GCC，当：
- 为嵌入式或小众硬件开发。
- 开发对稳定性要求极高的关键任务系统。
- 开发专有软件，且希望避免任何开源许可证传染风险（尤其是C++运行时库）。
- 需要最广泛的语言标准支持。
选择LLVM/Clang，当：
- 开发新的编程语言或编译器。
- 开发需要与现代IDE、静态分析、代码格式化深度集成的项目。
- 目标是macOS、iOS（Apple生态的官方工具链）或Windows（通过MSVC兼容模式）。
- 需要利用其先进的运行时检测工具或进行JIT编译。
- 项目参与一个开放、活跃的现代开源生态。
现状
如今，在x86-64和ARM64等主流桌面/服务器平台上，两者在代码生成质量上已旗鼓相当，经常是“互有胜负，差异在1%以内”。选择的决定性因素往往不再是性能，而是许可证、生态、工具链集成和平台支持等非技术因素。许多大型项目（如Linux内核、Android）都已支持用两者之一进行编译。
这场良性的“编译器战争”最终受益的是所有开发者。
