clang設置編譯器優化
1. Clang 比 GCC 好在哪裡
從代碼上說，clang結構更簡單。因為clang只需要完成詞法和語法分析，代碼優化和機器代碼的生成工作由llvm完成。所以和全部由自己包下的gcc比起來，clang可以更專注地做好一件事。
這種結構也使clang可以被單獨拿出來用在其他的程序里。比如vim的clang_complete插件就是利用clang進行語法分析後給出精確的自動補全和語法錯誤提示的。而gcc就沒法很方便地做到這一點。
在實用性方面，除了有更快的編譯速度更快和更友好的出錯提示外，clang還內置有靜態分析工具，可以對代碼進行靜態分析（clang --analyze）。這也是gcc做不到的。
總結如下：
Clang是LLVM的前端，可以用來編譯C，C++，ObjectiveC等語言。傳統的編譯器通常分為三個部分，前端(frontEnd)，優化器(Optimizer)和後端(backEnd)。
在編譯過程中，前端主要負責詞法和語法分析，將源代碼轉化為抽象語法樹；優化器則是在前端的基礎上，對得到的中間代碼進行優化，使代碼更加高效；後端則是將已經優化的中間代碼轉化為針對各自平台的機器代碼。Clang則是以LLVM為後端的一款高效易用，並且與IDE結合很好的編譯前端。
2. 如何設置來用clang/clang++替換Linux下的默認編譯器Gcc
是兩種不同的C++編譯器。gcc歷史很悠久了，而clang是新興的編譯器，已經兼容gcc，也全面支持C++11標准、Objective-C等，當然二者都是cross-platform的。具體的區別可以移步維基網路中gcc和clang詞條。
3. 綜合來說，幾大主流C++編譯器(icc,gcc,clang,vc++等)究竟孰優孰劣
我曾編出各種C++ 11編譯器的支持，並有C++ 14編譯器支持一批。
實際使用
對VC編譯的速度不斷提高，內存佔用已經從VC12開始明顯提高，而最明顯的是可變參數模板。還有內置的代碼靜態分析，在實際中很有用。32位保護模式下，ss寄存器存的是一個段選擇子，選擇子是一個數字，通過IDT(局部描述符表)或者GDT(全局描述符表)選擇一個段描述符，描述符裡面的信息包含該段的取值范圍和大小。
vc14的靜態分析不在每次載入一個ie（對，以前每分析一個.cpp，就載入一次ie！），速度快了相當多。
4. 如何讓clang編譯C代碼的時候，錯誤提示有顏色
1. 無選項編譯鏈接
> 用法: gcc test.c
> 作用：將test.c預處理、匯編、編譯並鏈接形成可執行文件。這里未指定輸出文件，默認輸出為a.out。
2. 選項 -o 第四步 鏈接(Linking)
> 用法: gcc test.c -o test
> 作用：將test.c預處理、匯編、編譯並鏈接形成可執行文件test。-o選項用來指定輸出文件的文件名。
3. 選項 -E 第一步 預處理(Pre-Processing)
> 用法: gcc -E test.c -o test.i
> 作用：將test.c預處理輸出test.i文件。
4. 選項 -S 第二步 編譯(Compiling)
> 用法: gcc -S test.i
> 作用：將預處理輸出文件test.i匯編成test.s文件。
5. 選項 -c 第三步 匯編(Assembling)
> 用法: gcc -c test.s
> 作用：將匯編輸出文件test.s編譯輸出test.o文件。
6. 無選項鏈接
> 用法: gcc test.o -o test
> 作用：將編譯輸出文件test.o鏈接成最終可執行文件test。
7. 選項 -O
> 用法: gcc -O1 test.c -o test
> 作用：使用編譯優化級別1編譯程序。級別為1~3，級別越大優化效果越好，但編譯時間越長。
二. 多源文件的編譯方法
1. 多個文件一起編譯
> 用法：#gcc testfun.c test.c -o test
> 作用：將testfun.c和test.c分別編譯後鏈接成test可執行文件。
2. 分別編譯各個源文件，之後對編譯後輸出的目標文件鏈接。
> 用法：
> gcc -c testfun.c //將testfun.c編譯成testfun.o
> gcc -c test.c //將test.c編譯成test.o
> gcc -o testfun.o test.o -o test //將testfun.o和test.o鏈接成test
5. 如何使用clang+llvm+binutils+newlib+gdb搭建交叉編譯環境
測試環境：Windows8.1 + MSYS2 with Mingw, Clang, LLVM + GNU Tools for ARM Embedded Processor
首先用用Clang生成LLVM位元組碼
clang -emit-llvm --target=arm-none-eabi -mcpu=cortex-m3 -mthumb -mfloat-abi=soft
注意，需要手動添加GNU Tools for ARM Embedd的頭文件
然後用llc生成匯編代碼
接著，使用GNU Tools for ARM Embedded Processor的匯編器生成可執行文件
arm-none-eabi-as -mcpu=cortex-m3 -mthumb -mfloat-abi=soft
二進制文件用GNU Tools for ARM Embedded Processor里的arm-none-eabi-obj生成
一些需要注意的地方是Clang的默認配置可能和目標架構的匯編器不一致。比如arm-none-eabi-as會默認開啟short-enums，當直接使用arm-none-eabi-gcc時這不是問題，因為編譯器也默認開啟了這個選項，但Clang不會，所以需要手動加上-fshort-enums。
6. clion中如何將默認編譯器設為clang
不建議在 CMakeLists.txt 裡面直接設置 CMAKE_CXX_COMPILER，畢竟文件里那部分是通用的。
可以在調用 cmake 的時候加上參數，如
cmake -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++
7. Clang 比 GCC 編譯器好在哪裡
1：Clang編譯速度更快、編譯產出更小、出錯提示更友好。
2：clang還內置有靜態分析工具，可以對代碼進行靜態分析（clang --analyze）。這是gcc做不到的。
3：clang結構更簡單。因為clang只需要完成詞法和語法分析，代碼優化和機器代碼的生成工作由llvm完成。所以和全部由自己包下的gcc比起來，clang可以更專注地做好一件事。
4：Clang 的另一個優勢是代碼結構清晰，可以作為庫使用，成為其它 app（主要是 IDE）的內嵌 C/C++ parser。這樣，editor 工具可以使用和 compiler 一樣的 parser 來完成 edit-time 的語法檢查。GCC 的結構比較混亂。業界一直有說法是 FSF 故意如此，以便讓 GCC 無法作為其它 app 的內嵌部分。
5：Clang採用的是BSD協議。這是蘋果資助LLVM、FreeBSD淘汰GCC換用Clang的一個重要原因。
8. 現代C/C++編譯器有多智能
最近在搞C/C++代碼的性能優化，發現很多時候自以為的優化其實編譯器早就優化過了，得結合反匯編才能看出到底要做什麼樣的優化。
請熟悉編譯器的同學結合操作系統和硬體談一談現代c/c++編譯器到底有多智能吧。哪些書本上的優化方法其實早就過時了？
以及程序員做什麼會讓編譯器能更好的自動優化代碼？
舉個栗子：
1，循環展開，大部分編譯器設置flag後會自動展開；
2，順序SIMD優化，大部分編譯器設置flag後也會自動優化成SIMD指令；
3，減少中間變數，大部分編譯器會自動優化掉中間變數；
etc.
查看代碼對應的匯編：
Compiler Explorer
【以下解答】
舉個之前看過的例子：
int calc_hash(signed char *s){ static const int N = 100003; int ret = 1; while (*s) { ret = ret * 131 + *s; ++ s; } ret %= N; if (ret < 0) ret += N; //注意這句 return ret;}
【以下解答】
舉個簡單例子，一到一百求和
#include int sum() { int ret= 0; int i; for(i = 1; i <= 100; i++) ret+=i; return ret;}int main() { printf("%d\n", sum()); return 0;}
【以下解答】
話題太大，碼字花時間…
先放傳送門好了。
請看Google的C++編譯器組老大Chandler Carruth的演講。這個演講是從編譯器研發工程師的角度出發，以Clang/LLVM編譯C++為例，向一般C++程序員介紹理解編譯器優化的思維模型。它講解了C++編譯器會做的一些常見優化，而不會深入到LLVM具體是如何實現這些優化的，所以即使不懂編譯原理的C++程序員看這個演講也不會有壓力。
Understanding Compiler Optimization - Chandler Carruth - Opening Keynote Meeting C++ 2015
演示稿：https://meetingcpp.com/tl_files/mcpp/2015/talks/meetingcxx_2015-understanding_compiler_optimization_themed_.pdf
錄像：https://www.youtube.com/watch?v=FnGCDLhaxKU（打不開請自備工具…）
Agner Fog寫的優化手冊也永遠是值得參考的文檔。其中的C++優化手冊：
Optimizing software in C++ - An optimization guide for Windows, Linux and Mac platforms - Agner Fog
要稍微深入一點的話，GCC和LLVM的文檔其實都對各自的內部實現有不錯的介紹。
GCC：GNU Compiler Collection (GCC) Internals
LLVM：LLVM』s Analysis and Transform Passes
========================================
反模式（anti-patterns）
1. 為了「優化」而減少源碼中局部變數的個數
這可能是最沒用的手工「優化」了。特別是遇到在高級語言中「不用臨時變數來交換兩個變數」這種場景的時候。
看另一個問題有感：有什麼像a=a+b;b=a-b;a=a-b;這樣的演算法或者知識？ - 編程
2. 為了「優化」而把應該傳值的參數改為傳引用
（待續…）
【以下解答】
推薦讀一讀這里的幾個文檔：
Software optimization resources. C++ and assembly. Windows, Linux, BSD, Mac OS X
其中第一篇：http://www.agner.org/optimize/optimizing_cpp.pdf
講解了C++不同領域的優化思路和問題，還有編譯器做了哪些優化，以及如何代碼配合編譯器優化。還有優化多線程、使用向量指令等的介紹，推薦看看。
感覺比較符合你的部分需求。
【以下解答】
一份比較老的slides：
http://www.fefe.de/source-code-optimization.pdf
【以下解答】
利用C++11的range-based for loop語法可以實現類似python里的range生成器，也就是實現一個range對象，使得
for(auto i : range(start, stop, step))
【以下解答】
我覺得都不用現代。。。。寄存器分配和指令調度最智能了
【以下解答】
每次編譯poco庫的時候我都覺得很為難GCC
【以下解答】
有些智能並不能保證代碼變換前後語義是等價的
【以下解答】
誒誒，我錯了各位，GCC是可以藉助 SSE 的 xmm 寄存器進行優化的，經 @RednaxelaFX 才知道應該添加 -march=native 選項。我以前不了解 -march 選項，去研究下再來補充為什麼加和不加區別這么大。
十分抱歉黑錯了。。。以後再找別的點來黑。
誤導大家了，實在抱歉。(??ˇ?ˇ??)
/*********以下是並不正確的原答案*********/
我是來黑 GCC的。
最近在搞編譯器相關的活，編譯OpenSSL的時候有一段這樣的代碼：
BN_ULONG a0,a1,a2,a3; // EmmetZC 註：BN_ULONG 其實就是 unsigned longa0=B[0]; a1=B[1]; a2=B[2]; a3=B[3];A[0]=a0; A[1]=a1; A[2]=a2; A[3]=a3;
【以下解答】
提示:找不到對象
【以下解答】
忍不住抖個機靈。
私以為正常寫代碼情況下編譯器就能優化，才叫智能編譯器。要程序員絞盡腦汁去考慮怎麼寫代碼能讓編譯器更好優化，甚至降低了可讀性，那就沒有起到透明屏蔽的作用。
智能編譯器應該是程序猿要較勁腦汁才能讓編譯器不優化。
理論上是這樣的。折疊我吧。
【以下解答】
編譯器智能到每次我都覺得自己很智障。
【以下解答】
雖然題主內容里是想問編譯器代碼性能優化方面的內容，但題目里既然說到編譯器的的智能，我就偏一下方向來說吧。
有什麼更能展示編譯器的強大和智能？
自然是c++的模版元編程
template meta programming
簡單解釋的話就是寫代碼的代碼，寫的還是c++，但能讓編譯器在編譯期間生成正常的c++代碼。
沒接觸過的話，是不是聽上去感覺就是宏替換的加強版？感覺不到它的強大呢？
只是簡單用的話，效果上這樣理解也沒什麼
但是一旦深入下去，尤其翻看大神寫的東西，這明明看著就是c++的代碼，但TM怎麼完全看不懂他在干什麼？後來才知道這其實完全是另外一個世界，可是明明是另外一個世界的東西但它又可以用來做很多正常c++能做的事....
什麼？你說它好像不能做這個，不能做那個，好像做不了太多東西，錯了，大錯特錯。就像你和高手考試都考了100分的故事一樣，雖然分數一樣，但你是努力努力再努力才得了滿分，而高手只是因為卷面分只有100分.....在元編程面前，只有想不到，沒有做不到。
再回頭看看其他答案，編譯器順手幫你求個和，丟棄下無用代碼，就已經被驚呼強大了，那模板元編程這種幾乎能在編譯期直接幫你「生成」包含復雜邏輯的c++代碼，甚至還能間接「執行」一些復雜邏輯，這樣的編譯器是不是算怪獸級的強大？
一個編譯器同時支持編譯語法相似但結果不同卻又關聯的兩種依賴語言，這個編譯器有多強大多智能？
寫的人思維都要轉換幾次，編譯器轉著圈嵌著套翻著番兒地編譯代碼的代碼也肯定是無比蛋疼的，你說它有多強大多智能？
一個代碼創造另外一個代碼，自己能按照相似的規則生成自己，是不是聽上去已經有人工智慧的發展趨勢了？
上帝說，要有光，於是有了光。
老子曰，一生二，二生三，三生萬物。
信c++，得永生！
===
FBI WARNING：模板元編程雖然很強大，但也有不少缺點，尤其對於大型項目，為了你以及身邊同事的身心健康，請務必適度且謹慎的使用。勿亂入坑，回頭是岸。
【以下解答】
c++11的auto自動類型推斷算么....
【以下解答】
智能到開不同級別的優化，程序行為會不同 2333
【以下解答】
這個取決於你的水平