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