伯樂線上注：“優化C++程式碼”系列博文，Ｃ++程式媛 JingerJoe（@米可_GO）將會持續更新翻譯，感興趣的朋友，請收藏並關注。如果其他朋友也有不錯的原創或譯文，可以嘗試推薦給伯樂線上。
此處已是系列博文的第二篇，你最好從頭開始看吧。
這篇文章會講解 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所包含的的任何二進位制檔案裡。後端先將資訊從前端轉換為元組—–一個二進位制流的指令。顯示出來會看到它們看上去就像是一種高階組合語言。感覺上很高階：
1. 操作是通用的，例如，一個分支（LE）指令,以及它最終如何被翻譯成64位的機器碼CMP指令。
2. 運算元是象徵性的，例如，一個由編譯器生成的臨時變數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 ，優於一些更直接的指令 mov eax,0 為什麼呢？因為XOR 指令更小（只有2個位元組），執行速度更快。我們也稱它為“微優化”，也許你會懷疑是否值得這麼麻煩？還記得那句諺語嗎？積少才能成多。)
與優化相比，CodeGen就必須很清楚程式碼將要執行的處理器架構。有些情況下，在理解目標處理器的基礎上，它甚至會改變機器指令的佈局順序—–稱之為‘排程’。我最好還是再解釋一下： CodeGen知道它是針對x86，x64還是ARM-32， 知道程式碼將要執行的處理器的具體的微架構還是很罕見的，以 Nehalem和Sandy Bridge為例（看看/favor:ATOM 這個案例，可以更多的詳情）
這篇文章重點講編譯器的優化部分，很少提及構成前端， CodeGen或者連結器的其他元件。
這篇文章介紹了大量的術語，我沒有打算讓你全部理解它們：畢竟這只是一篇概述，傳播一些思想，希望你會感興趣，確保讀完你下次還會再來，我會開始講解所有的術語。
下次，我們一起來看看最簡單的一種優化方法和它的工作原理——–合併常量。