GCC: GNU Compiler Collection
GCC屬于傳統(tǒng)編譯器，傳統(tǒng)編譯器的工作原理基本上都是三段式的，可以分為前端（Frontend）、優(yōu)化器（Optimizer）、后端（Backend）。前端負責(zé)解析源代碼，檢查語法錯誤，并將其翻譯為抽象的語法樹（Abstract Syntax Tree）。優(yōu)化器對這一中間代碼進行優(yōu)化，試圖使代碼更高效。后端則負責(zé)將優(yōu)化器優(yōu)化后的中間代碼轉(zhuǎn)換為目標機器的代碼，這一過程后端會最大化的利用目標機器的特殊指令，以提高代碼的性能。
事實上，不光靜態(tài)語言如此，動態(tài)語言也符合上面這個模型，例如Java。Java Virtual Machine也利用上面這個模型，將Java代碼翻譯為Java bytecode。這一模型的好處是，當我們要支持多種語言時，只需要添加多個前端就可以了。當需要支持多種目標機器時，只需要添加多個后端就可以了。對于中間的優(yōu)化器，我們可以使用通用的中間代碼。
這種三段式的結(jié)構(gòu)還有一個好處，開發(fā)前端的人只需要知道如何將源代碼轉(zhuǎn)換為優(yōu)化器能夠理解的中間代碼就可以了，他不需要知道優(yōu)化器的工作原理，也不需要了解目標機器的知識。這大大降低了編譯器的開發(fā)難度，使更多的開發(fā)人員可以參與進來。
雖然這種三段式的編譯器有很多有點，并且被寫到了教科書上，但是在實際中這一結(jié)構(gòu)卻從來沒有被完美實現(xiàn)過。做的比較好的應(yīng)該屬Java和.NET虛擬機。虛擬機可以將目標語言翻譯為bytecode，所以理論上講我們可以將任何語言翻譯為bytecode，然后輸入虛擬機中運行。但是這一動態(tài)語言的模型并不太適合C語言，所以硬將C語言翻譯為bytecode并實現(xiàn)垃圾回收機制的效率是非常低的。
GCC也將三段式做的比較好，并且實現(xiàn)了很多前端，支持了很多語言。但是上述這些編譯器的致命缺陷是，他們是一個完整的可執(zhí)行文件，沒有給其它語言的開發(fā)者提供代碼重用的接口。即使GCC是開源的，但是源代碼重用的難度也比較大。

LLVM: Low Level Virtual Machine
LLVM最初是[Low Level Virtual Machine]的縮寫，定位是一個虛擬機，但是是比較底層的虛擬機。它的出現(xiàn)正是為了解決編譯器代碼重用的問題，LLVM一上來就站在比較高的角度，制定了LLVM IR這一中間代碼表示語言。LLVM IR充分考慮了各種應(yīng)用場景，例如在IDE中調(diào)用LLVM進行實時的代碼語法檢查，對靜態(tài)語言、動態(tài)語言的編譯、優(yōu)化等。
LLVM與GCC在三段式架構(gòu)上并沒有本質(zhì)區(qū)別。LLVM與其它編譯器最大的差別是，它不僅僅是Compiler Collection，也是Libraries Collection。舉個例子，假如說我要寫一個XYZ語言的優(yōu)化器，我自己實現(xiàn)了PassXYZ算法，用以處理XYZ語言與其它語言差別最大的地方。而LLVM優(yōu)化器提供的PassA和PassB算法則提供了XYZ語言與其它語言共性的優(yōu)化算法。那么我可以選擇XYZ優(yōu)化器在鏈接的時候把LLVM提供的算法鏈接進來。LLVM不僅僅是編譯器，也是一個SDK。
Clang錯誤提示比GCC友好得多。