優化C++代碼（2）:Ｃ++代碼的編譯過程
此處已是系列博文的第二篇，你最好從頭開始看吧。
這篇文章會講解 Visual C++ 編譯器的數據流——首先會以一段C++源程序開始，以對應的二進制程序結束。這篇文章很簡單——一切才剛剛開始。
首先我們來看看從命令行開始，編譯一個單一文件的程序 APP.cpp 時會發生什么（如果你想從Vistual Studio 來啟動編譯，下圖還必須包含一些高層軟件，然而,結束時,它們會給出一些很特別的命令，我后面會講到）。
假設我們剛才鍵入了: CL/02 App.cpp
CL代表‘編譯和鏈接’，02告訴編譯器優化速度—-生成一些執行速度盡可能快的機器碼。該命令啟動一個進程去運行CL.EXE程序—- 一個調用了其他軟件的驅動器：連接到一起時，他們會處理APP.cpp里的文本，最終生產一個二進制文件，成為App.exe。 執行時，該二進制文件會執行我們源代碼里的操作。
我們瀏覽下上個圖表，看看發生了什么。
CL．EXE 解析我們的命令行，并檢查它是否有意義。然后調用位于C1XX.DLL的 C++‘前端’（“CXX”是指C++，因為以前‘+’不能用于文件名。）前端是用于理解C++語言的一條鏈。它掃描，解析并將APP.cpp文件轉換為 一顆等價樹，通過五個臨時文件傳遞給下一個組件。這五個文件被稱為CIL，意為C中間語言。不要把它跟托管語言，例如C#生產的中間代碼混淆。有時，也成 為MSIL，但是不幸的是，在ECMA-335標準里，它被命名為CIL。
接下來,CL.EXE會調用 所謂的‘后端’，位于C2.DLL。我們把后端成為‘UTC’，意思為‘通用元組編譯器’，但是這個名字并沒有出現在Visual Studio所包含的的任何二進制文件里。后端先將信息從前端轉換為元組—–一個二進制流的指令。顯示出來會看到它們看上去就像是一種高級匯編語言。感覺 上很高級：
- 操作是通用的，例如，一個分支（LE）指令,以及它最終如何被翻譯成64位的機器碼CMP指令。
- 操作數是象征性的，例如，一個由編譯器生成的臨時變量t66和一個運行時保存其值得64位寄存器eax。
因為我們要求編譯器優化速度，通過/02開關，優化部分后端，分析元組并將其轉化為另一種形式，使其運行得更快，但是語義上來講，卻是等價的，和原來的元組產生的同樣的結果。完成這步后，元組就會被傳給后端的CodeGen部分，最終會決定二進制碼的產生。
CodeGen模塊會在磁盤上生成APP.obj文件，最后，鏈接器會利用該文件，并分析所有的引用庫，生成最終的二進制文件App.exe。
在上面的圖表中，黑色箭頭顯示數據流（文本或者二進制文件），紅色箭頭表示控制流。
（在該系列的后面文章里，當我們涉及到整個程序的優化，關于特定的/GL開關編譯器和/LTCG開關的鏈接器時，還會再回到這個圖表。 我們看到的是相同的框圖，但是卻以不同方式連接起來的。）
小結：
1. 前端需要理解C++源代碼，其他環節，像后端和鏈接器，大部分都是獨立于原始源語言的。他們工作在上面提到的元組上，形成一種更高層次的二進制匯編語言。原始的源程序可以是任何的命令式語言，像FORTRAN或者Pascal。后端真的不會在意。
2. 后端的優化部分會將元組轉換成運行更快的更有效的形式，這種轉換，我們稱之為優化。(其實我們應該稱之為’改進’，因為還有其他的改進，可以產生運行更快 的代碼——我們只是盡力接近理想狀態。 然而，幾十年前，有人創造了一個術語’優化’，我們都深陷其中。) 還有很多這樣的優化方法，像’常量合并’、’消除公共子表達式’、 ‘提升’、 ‘外提不變表達式’、‘冗余代碼消除’、’ 內聯函數’、 ‘自動向量化’等等.。大多數情況下。這些優化都是獨立于程序所運行的最終處理器—–他們都是獨立于機器的優化。
3. 后端的CodeGen部分決定如何制定運行時堆棧(用于實現’激活框架’)；怎么樣充分利用可用的機器寄存器；添加函數調用約定的細節；使用目標機器的詳細介紹來轉換代碼，讓它運行得更快。
(舉一個小例子，如果你看匯編代碼，例如，你在調試代碼的時候，同時使用Visual Studio(Alt+8)的反匯編窗口—- 你可能會注意到一些用于將EAX置為0的指令像 xor eax, eax ，優于一些更直接的指令 move eax,0. 為什么呢？因為XOR 指令更小（只有2個字節），執行速度更快。我們也稱它為“微優化”，也許你會懷疑是否值得這么麻煩？還記得那句諺語嗎？積少才能成多。)
與優化相比，CodeGen就必須很清楚代碼將要運行的處理器架構。有些情況下，在理解目標處理器的基礎上，它甚至會改變機器指令的布局順序—–稱 之為‘調度’。我最好還是再解釋一下： CodeGen知道它是針對x86，x64還是ARM-32， 知道代碼將要運行的處理器的具體的微架構還是很罕見的，以 Nehalem和Sandy Bridge為例（看看/favor:ATOM 這個案例，可以更多的詳情）
這篇文章重點講編譯器的優化部分，很少提及構成前端， CodeGen或者鏈接器的其他組件。
這篇文章介紹了大量的術語，我沒有打算讓你全部理解它們：畢竟這只是一篇概述，傳播一些思想，希望你會感興趣，確保讀完你下次還會再來，我會開始講解所有的術語。
下次，我們一起來看看最簡單的一種優化方法和它的工作原理——–合并常量。
原文鏈接：http://blogs.msdn.com/b/vcblog/archive/2013/06/12/optimizing-c-code-new-title.aspx
