㈠ 比較gcc，llvm和商用編 譯器的性能差異，說明是什麼原因導致差異 的出現
Apple在LLVM GCC4.2編譯器中，通過XCode中的提示介面顯式地為程序員提供是否將目標代碼編譯為ARM的選項。而在Apple LLVM3.0中，此選項沒有了。
由於採用ARMv7A架構的Apple A4/A5處理器擁有Thumb-2指令集，使得Thumb代碼在確保緊湊性的同時又進一步提升了計算能力。因此，Apple將工程配置默認設置為編譯為Thumb代碼。
而又由於LLVM的編譯選項基本與GCC兼容，因此我們只需要在編譯選項中手動加入-marm即可。
而傳統GCC的編譯選項只有-mthumb，它默認將代碼編譯為ARM指令集，因此可能沒有提供-marm的編譯選項。不過-marm在Apple LLVM3.0中確實奏效了。
㈡ 安裝xcode 6後，為什麼在MAC電腦的terminal里打gcc -v 會顯示LLVMLLVM和GCC不是兩個不同的編譯器嗎
Mac OS 現在都是默認使用clang+llvm編譯，以前使用gcc+llvm。
只是現在還可以使用gcc命令 [編譯實際還是用clang+llvm編譯]。
要想用gcc, 需要自己單獨裝。
㈢ llvm怎樣將中間代碼編譯為可執行二進制文件
預編譯。編譯器將你的.c、.cpp源代碼，通過解釋其中的預編譯指令，將源代碼轉換成相應的沒有任何預編譯指令的代碼。
編譯、優化。將上一步的代碼編譯成匯編指令，並作一定優化，形成對應的.s匯編代碼
匯編。將.s文件匯編成機器碼，形成對應的.o目標文件，此時是不可執行的二進制文件。生成對應的清單文件。為了連接需要，還會生成未定向符號表、導出符號表、地址重定向表等等。
連接。先根據對應的清單文件、連接文件及之間的調用關系，決定所有的目標文件及引用的庫文件在最後可執行文件中的位置；然後做一些其他事情，比如根據符號表等將目標文件中的符號地址補全等等；最終得到可執行文件。
這只是我個人的簡單理解，更詳盡的解答都可以寫成好幾本書了=_=望採納~
㈣ Gcc和llvm編譯器有什麼區別，我這配置哪個快
LLVM與GCC在三段式架構上並沒有本質區別。LLVM與其它編譯器最大的差別是，它不僅僅是Compiler Collection，也是Libraries Collection。舉個例子，假如說我要寫一個XYZ語言的優化器，我自己實現了PassXYZ演算法，用以處理XYZ語言與其它語言差別最大的地方。而LLVM優化器提供的PassA和PassB演算法則提供了XYZ語言與其它語言共性的優化演算法。那麼我可以選擇XYZ優化器在鏈接的時候把LLVM提供的演算法鏈接進來。LLVM不僅僅是編譯器，也是一個SDK。
㈤ 怎麼告訴編譯器去找llvm/support/host.h
首先是編譯，然後是鏈接。
編譯器會將所有.cpp文件編譯成中間文件.o，編譯時遇到.h文件則讀入各種（函數，變數等）的聲明，此時並不讀入對應的.cpp文件。
鏈接時會將各個.o文件連接成可執行文件。
所以，編譯器並不是看到.h文件後立即自動去找同名的.cpp文件，而是將所有的.cpp文件編譯成.o文件後一並鏈接。
㈥ 編譯器二：LLVM和GCC的區別
GCC: GNU Compiler Collection
GCC屬於傳統編譯器，傳統編譯器的工作原理基本上都是三段式的，可以分為前端（Frontend）、優化器（Optimizer）、後端（Backend）。前端負責解析源代碼，檢查語法錯誤，並將其翻譯為抽象的語法樹（Abstract Syntax Tree）。優化器對這一中間代碼進行優化，試圖使代碼更高效。後端則負責將優化器優化後的中間代碼轉換為目標機器的代碼，這一過程後端會最大化的利用目標機器的特殊指令，以提高代碼的性能。
事實上，不光靜態語言如此，動態語言也符合上面這個模型，例如Java。Java Virtual Machine也利用上面這個模型，將Java代碼翻譯為Java bytecode。這一模型的好處是，當我們要支持多種語言時，只需要添加多個前端就可以了。當需要支持多種目標機器時，只需要添加多個後端就可以了。對於中間的優化器，我們可以使用通用的中間代碼。
這種三段式的結構還有一個好處，開發前端的人只需要知道如何將源代碼轉換為優化器能夠理解的中間代碼就可以了，他不需要知道優化器的工作原理，也不需要了解目標機器的知識。這大大降低了編譯器的開發難度，使更多的開發人員可以參與進來。
雖然這種三段式的編譯器有很多有點，並且被寫到了教科書上，但是在實際中這一結構卻從來沒有被完美實現過。做的比較好的應該屬Java和.NET虛擬機。虛擬機可以將目標語言翻譯為bytecode，所以理論上講我們可以將任何語言翻譯為bytecode，然後輸入虛擬機中運行。但是這一動態語言的模型並不太適合C語言，所以硬將C語言翻譯為bytecode並實現垃圾回收機制的效率是非常低的。
GCC也將三段式做的比較好，並且實現了很多前端，支持了很多語言。但是上述這些編譯器的致命缺陷是，他們是一個完整的可執行文件，沒有給其它語言的開發者提供代碼重用的介面。即使GCC是開源的，但是源代碼重用的難度也比較大。
LLVM: Low Level Virtual Machine
LLVM最初是[Low Level Virtual Machine]的縮寫，定位是一個虛擬機，但是是比較底層的虛擬機。它的出現正是為了解決編譯器代碼重用的問題，LLVM一上來就站在比較高的角度，制定了LLVM IR這一中間代碼表示語言。LLVM IR充分考慮了各種應用場景，例如在IDE中調用LLVM進行實時的代碼語法檢查，對靜態語言、動態語言的編譯、優化等。
LLVM與GCC在三段式架構上並沒有本質區別。LLVM與其它編譯器最大的差別是，它不僅僅是Compiler Collection，也是Libraries Collection。舉個例子，假如說我要寫一個XYZ語言的優化器，我自己實現了PassXYZ演算法，用以處理XYZ語言與其它語言差別最大的地方。而LLVM優化器提供的PassA和PassB演算法則提供了XYZ語言與其它語言共性的優化演算法。那麼我可以選擇XYZ優化器在鏈接的時候把LLVM提供的演算法鏈接進來。LLVM不僅僅是編譯器，也是一個SDK。
㈦ 如何利用LLVM寫一個編譯器
LLVM有自己的教程，如果你只想做個玩具，那可以首先試著實現LLVM Tutorial: Table of Contents的Kaleidoscope。深入的，請看他的文檔http://llvm.org/docs/
Kaleidoscope是一個範式簡單的腳本語言，教程里的詞法，語法分析都是手寫的，基本流程就是詞法語法解析，利用LLVM的API生成中間代碼並執行。
我用visual studio編譯的LLVM(version 3.6)實現過Kaleidoscope，我遇到的坑不少，如果你想以visual studio編譯的LLVM實現Kaleidoscope，你可能同樣會遇到
1. LLVM的生成目標對象為ELF格式，在windows下使用JIT的API時會出現incompatible object format的錯誤警告，需要在通過重新設定Mole的triple，我的PC的getTargetTriple的結果是「i686-pc-windows-msvc」，直接在後面再加上「-elf」即可
TheMole->setTargetTriple("i686-pc-windows-msvc-elf");
2. LLVM不支持windows下通過動態鏈接導出函數，如果需要使用C/C++的函數，需要通過addSymbol進行注冊
llvm::sys::DynamicLibrary::AddSymbol(/*std::string("_") +*/ "printd", &printd);
3. Kaleidoscope里使用的JIT的查找函數的API，getPointerToFunction已經被棄用了，需要替換為getFunctionAddress
㈧ LLVM相比於GCC，有哪些技術上的優勢
首先簡要介紹一下LLVM。LLVM是一個針對LLVM Intermediate Representation（IR，中間語言）的跨平台優化編譯器，它的模塊化設計很好，使得這個編譯器中的很多功能可以被單獨實現或者改進，這與其C++實現無法分開。由此，LLVM可以被設計成很多語言編譯器實現的後端，負責處理程序優化和跨平台，而前端只需將程序轉換成LLVM IR即可。比如說，Clang就是基於LLVM實現的C/C++編譯器，它的主要功能就是將C/C++程序轉換成LLVM IR，然後由LLVM負責後續的工作。
LLVM技術上的（最大）優勢就在於它的模塊化設計。在LLVM中，IR的解析，優化，匯編碼的生成，寄存器分配，匯編碼優化以及機器碼生成，各種類型的二進制文件生成全部都是介面定義清晰的模塊完成的，很容易分別改進或者添加定製功能。而且由於LLVM的C++實現，很多模塊理解和使用比較容易。這些特性使得LLVM可以很容易地被用在科研和生產實踐當中。反觀GCC，模塊化做得不如LLVM好，這使得它定製或者改進比較不方便。
㈨ 編譯llvm和clang需要多大空間
：轉自知乎 藍色 我最近和Clang/LLVM打交道比較多，目前游離在LLVM IR和IBM WCode之間。對於學習Clang/LLVM來說，其實需要看你做什麼，是研究C, C++, Objective-C在Clang的實現，抑或著是想利用Clang做AST層面的事情，還是說想要利用LLVM IR來做
㈩ 怎麼用llvm編譯器編寫c語言
LLVM的幫助。對於這個工具,我不知道改怎麼去形容它,但是他給我的這個編譯器的確帶... 我們使用的工具是基於C/...LLVM是構架編譯器(compiler)的框架系統，以C++編寫而成，用於優化以任意程序語言編寫的程序的編譯時間(compile-time)、鏈接時間(link-time)、運行時間(run-tim...