GCC，LLVM，Clang編譯器對比

http://www.cnblogs.com/qoakzmxncb/archive/2013/04/18/3029105.html

 

在XCode中，咱們常常會看到這些編譯選項（以下圖），有些人可能會有些茫然，本文將對GCC4.二、LLVM GCC 4.二、LLVM compliler 2.0三個編譯選項進行一個詳細的介紹。

 

GCC

    GCC（GNU Compiler Collection，GNU編譯器套裝），是一套由 GNU 開發的編程語言編譯器。它是一套以 GPL 及 LGPL 許可證所發行的自由軟件，也是 GNU計劃的關鍵部分，亦是自由的類Unix及蘋果電腦 Mac OS X 操做系統的標準編譯器。

GCC 原名爲 GNU C 語言編譯器，由於它本來只能處理 C語言。GCC 很快地擴展，變得可處理 C++。以後也變得可處理 Fortran、Pascal、Objective-C、Java, 以及 Ada與其餘語言。

 

LLVM

     LLVM 是 Low Level Virtual Machine 的簡稱，這個庫提供了與編譯器相關的支持，可以進行程序語言的編譯期優化、連接優化、在線編譯優化、代碼生成。簡而言之，能夠做爲多種語言編譯器的後臺來使用。若是這樣還比較抽象的話，介紹下 Clang 就知道了：Clang 是一個 C++ 編寫、基於 LLVM、發佈於 LLVM BSD 許可證下的 C/C++/Objective C/Objective C++ 編譯器，其目標（之一）就是超越 GCC。

 

LLVM歷史

    Apple（包括中後期的NeXT） 一直使用GCC做爲官方的編譯器。GCC做爲開源世界的編譯器標準一直作得不錯，但Apple對編譯工具會提出更高的要求。

    一方面，是Apple對Objective-C語言（甚至後來對C語言）新增不少特性，但GCC開發者並不買Apple的賬——不給實現，所以索性後來二者分紅兩條分支分別開發，這也形成Apple的編譯器版本遠落後於GCC的官方版本。另外一方面，GCC的代碼耦合度過高，很差獨立，並且越是後期的版本，代碼質量越差，但Apple想作的不少功能（好比更好的IDE支持）須要模塊化的方式來調用GCC，但GCC一直不給作。甚至最近，《GCC運行環境豁免條款 （英文版）》從根本上限制了LLVM-GCC的開發。 因此，這種不和讓Apple一直在尋找一個高效的、模塊化的、協議更放鬆的開源替代品，因而Apple請來了編譯器高材生Chris Lattner（2000年，本科畢業的Chris Lattner像中國多數大學生同樣，循序漸進地考了GRE，最終前往UIUC（伊利諾伊大學厄巴納香檳分校），開始了艱苦讀計算機碩士和博士的生涯。在這階段，他不只周遊美國各大景點，更是努力學習科學文化知識，翻爛了「龍書」（《Compilers: Principles, Techniques, and Tools》），成了GPA牛人【注：最終學分積4.0滿分】，以及不斷地研究探索關於編譯器的未知領域，發表了一篇又一篇的論文，是中國傳統觀念裏的「三好學生」。他的碩士畢業論文提出了一套完整的在編譯時、連接時、運行時甚至是在閒置時優化程序的編譯思想，直接奠基了LLVM的基礎。LLVM在他念博士時更加成熟，使用GCC做爲前端來對用戶程序進行語義分析產生IF（Intermidiate Format），而後LLVM使用分析結果完成代碼優化和生成。這項研究讓他在2005年畢業時，成爲小有名氣的編譯器專家，他也所以早早地被Apple相中，成爲其編譯器項目的骨幹）。

    剛進入Apple，Chris Lattner就大展身手：首先在OpenGL小組作代碼優化，把LLVM運行時的編譯架在OpenGL棧上，這樣OpenGL棧可以產出更高效率的圖形代碼。若是顯卡足夠高級，這些代碼會直接扔入GPU執行。但對於一些不支持所有OpenGL特性的顯卡（好比當時的Intel GMA卡），LLVM則可以把這些指令優化成高效的CPU指令，使程序依然可以正常運行。這個強大的OpenGL實現被用在了後來發佈的Mac OS X 10.5上。同時，LLVM的連接優化被直接加入到Apple的代碼連接器上，而LLVM-GCC也被同步到使用GCC4代碼。

 

Clang歷史

    Apple吸取Chris Lattner的目的要比改進GCC代碼優化宏大得多——GCC系統龐大而笨重，而Apple大量使用的Objective-C在GCC中優先級很低。此外GCC做爲一個純粹的編譯系統，與IDE配合得不好。加之許可證方面的要求，Apple沒法使用LLVM 繼續改進GCC的代碼質量。因而，Apple決定從零開始寫 C、C++、Objective-C語言的前端 Clang，徹底替代掉GCC。

    正像名字所寫的那樣，Clang只支持C，C++和Objective-C三種C家族語言。2007年開始開發，C編譯器最先完成，而因爲Objective-C相對簡單，只是C語言的一個簡單擴展，不少狀況下甚至能夠等價地改寫爲C語言對Objective-C運行庫的函數調用，所以在2009年時，已經徹底能夠用於生產環境。C++的支持也熱火朝天地進行着。

 

    下面這張圖將顯示GCC、LLVM-GCC、LLVM Compiler這三個編譯選項的不一樣點：

 

對比    

    做爲一種新的編譯器，咱們來看Clang和GCC各有什麼優缺點：

    Clang特性

1. 快：經過編譯 OS X 上幾乎包含了全部 C 頭文件的 carbon.h 的測試，包括預處理 (Preprocess)，語法 (lex)，解析 (parse)，語義分析 (Semantic Analysis)，抽象語法樹生成 (Abstract Syntax Tree) 的時間，Clang 是 Apple GCC 4.0 的 2.5x 快。(2007-7-25)

1. 內存佔用小：Clang 內存佔用是源碼的 130%，Apple GCC 則超過 10x。
2. 診斷信息可讀性強：我不會排版，推薦去網站觀看。其中錯誤的語法不但有源碼提示，還會在錯誤的調用和相關上下文的下方有~~~~~和^的提示，相比之下 GCC 的提示很天書。
3. GCC 兼容性。
4. 設計清晰簡單，容易理解，易於擴展加強。與代碼基礎古老的 GCC 相比，學習曲線平緩。
5. 基於庫的模塊化設計，易於 IDE 集成及其餘用途的重用。因爲歷史緣由，GCC 是一個單一的可執行程序編譯器，其內部完成了從預處理到最後代碼生成的所有過程，中間諸多信息都沒法被其餘程序重用。Clang 將編譯過程分紅彼此分離的幾個階段，AST 信息可序列化。經過庫的支持，程序可以獲取到 AST 級別的信息，將大大加強對於代碼的操控能力。對於 IDE 而言，代碼補全、重構是重要的功能，然而若是沒有底層的支持，只使用 tags 分析或是正則表達式匹配是很難達成的。

     固然，GCC 也有其優點：

• 支持 JAVA/ADA/FORTRAN
• 當前的 Clang 的 C++ 支持落後於 GCC，參見http://clang.llvm.org/cxx_status.html。（近日 Clang 已經能夠自編譯，見http://www.phoronix.com/scan.php?page=news_item&px=Nzk2Mw）
• GCC 支持更多平臺
• GCC 更流行，普遍使用，支持完備
• GCC 基於 C，不須要 C++ 編譯器便可編譯

要選擇哪一個

     那麼三個編譯選項，要選擇哪個呢？目前不推薦使用老的GCC4.2，由於蘋果不會維持它了，並且LLVM-GCC看起來會更好。在項目中途改編譯選項但是一個大變更，因此，若是你要改，固然須要通過慎重完整的測試。

    對新的項目而言，LLVM-GCC看起來應該是個安全的選擇，蘋果公司認爲它夠穩定夠成熟，因此才把它當作Xcode 4的預設選項（你或許不會把穩定成熟這兩個字眼跟Xcode 4自己畫上等號），並且，既然選項使用的是GCC parser，向後兼容性應該沒問題。     我說LLVM-GCC是個安全的選項，但我並非指Clang/LLVM比較不安全，只是成熟度還沒那麼高效了，我將一些之前的代碼拿到Xcode 4上，使用LLVM 2.0編譯器從新編譯，到目前爲止還沒發現任何問題。