1. 先從基礎(chǔ)說起-O 優(yōu)化到底在優(yōu)化什么編譯器gcc、clang、msvc 這些本質(zhì)上是一個翻譯官把人類能讀懂的 C/C 代碼翻譯成機器能執(zhí)行的匯編指令。但翻譯和翻譯之間差距很大——剛?cè)腴T的翻譯可能逐字逐句硬譯老練的翻譯會調(diào)整語序、精簡表達(dá)、合并重復(fù)內(nèi)容讓譯文更流暢。編譯器的 -O 優(yōu)化就是干這個的只是它優(yōu)化的不是語言的優(yōu)美程度而是執(zhí)行速度、代碼體積、功耗這些硬指標(biāo)。很多剛接觸嵌入式或者 Linux 下 C 開發(fā)的人第一次看到gcc -O2 -o app main.c這種命令都會愣一下這個-O2是什么為什么有時候是-O0有時候是-Os還有-Og、-O1、-O3它們之間到底差在哪先說一句最關(guān)鍵的話-O 后面對應(yīng)的數(shù)字越小編譯速度越快、生成的代碼越容易調(diào)試數(shù)字越大編譯時間越長、運行速度越快但出問題的概率也越高。這里面每個級別的取舍都值得掰開揉碎講清楚因為選錯優(yōu)化等級輕則程序崩潰重則線上事故、數(shù)據(jù)錯亂。2. 一份速查表主流 -O 選項到底有哪些我先把目前 gcc 和 clang 里最常見的優(yōu)化等級列出來方便你對照著看后面每一節(jié)的內(nèi)容。順手加一句msvc微軟的 C 編譯器也有類似的/O1、/O2、/Ox選項原理和 gcc 基本互通看懂了 gcc 的換到 Visual Studio 里也能舉一反三。選項全稱含義核心目標(biāo)常用場景-O0不優(yōu)化調(diào)試體驗優(yōu)先Debug 版本、斷點調(diào)試、上課學(xué)編譯原理-O1輕度優(yōu)化在編譯速度和運行速度間找平衡快速驗證邏輯、舊編譯器兼容、部分嵌入式工程-O2推薦優(yōu)化穩(wěn)定且全面的性能提升絕大多數(shù)項目的 Release 默認(rèn)選項-O3激進(jìn)優(yōu)化極致性能不限編譯時間數(shù)值計算、音視頻編解碼、科學(xué)仿真-Os優(yōu)化體積生成盡量小的代碼單片機 Flash 受限、固件、內(nèi)核模塊-Og優(yōu)化調(diào)試優(yōu)化但保留完整調(diào)試信息開發(fā)中后期、調(diào)試 Release 問題-Ofast無視標(biāo)準(zhǔn)-O3基礎(chǔ)上放寬標(biāo)準(zhǔn)約束追求速度且不 care 精度邊界約束的場景慎用每家編譯器對各個等級的精細(xì)實現(xiàn)略有差異但整體邏輯高度一致。下面我把-O0到-Os逐個講透每個等級背后的“為什么”才是真正值錢的部分。2.1 中間表示IR這個概念你得先知道要理解優(yōu)化級別最好先知道編譯器內(nèi)部干活時的核心結(jié)構(gòu)。gcc 在把 C 代碼變成匯編之前會先翻譯成一種叫 GIMPLE 的中間表示clang 則叫 LLVM IR。優(yōu)化就是在這個中間表示上做變換比如“這行計算和后面那行重復(fù)了刪掉一個”“這個變量只有一處用直接替換成值”。不同的優(yōu)化等級就是打開不同數(shù)量和種類的變換開關(guān)。這個和做菜挺像-O0相當(dāng)于把菜洗好切好就端上桌能看但沒加工-O1相當(dāng)于大火快炒熟了但沒入味-O2相當(dāng)于精心烹飪色香味俱全-O3相當(dāng)于用名貴食材和高湯反復(fù)熬制極致好吃但費時費力還可能把食材本味搞沒。3. -O0不優(yōu)化才是最適合調(diào)試的-O0是 gcc 的默認(rèn)優(yōu)化等級。如果你直接執(zhí)行g(shù)cc main.c -o app等效于gcc -O0 main.c -o app。它的核心原則是保持可觀察行為與源代碼嚴(yán)格一致。這是什么意思舉個例子int add(int a, int b) { int tmp a b; return tmp; }-O0編譯時gcc 會老老實實給tmp分配一個?？臻g先算ab存進(jìn)去再讀出來返回。每一步都對應(yīng)源碼里的每一行中間變量一個不少。你在調(diào)試器里打斷點想查看tmp的值它就在那里清清楚楚。但如果用-O2編譯同一段代碼tmp這個變量可能直接消失了——編譯器發(fā)現(xiàn)tmp只是轉(zhuǎn)了一道手完全可以把ab的值直接放進(jìn)返回值寄存器中間那個臨時變量既沒存活期也沒副作用。這時候你在調(diào)試器里想查看tmpgdb 會告訴你value optimized out。這就是為什么調(diào)試階段尤其是剛寫完一個模塊需要逐步確認(rèn)邏輯時一定要用-O0。3.1 -O0 也不是字面意義上的“不優(yōu)化”很多初學(xué)者誤以為-O0是編譯器什么都不干直接把代碼機械翻譯。實際上gcc 在-O0下仍會做一些必要處理比如把常量表達(dá)式折疊const int x 10; int y x * 2;這種在編譯期就能算出y 20的還是會算出來。做一些最基礎(chǔ)的指令選擇比如用乘法指令還是移位加加法。對明顯的棧幀布局做規(guī)劃。只是這些操作不會改變調(diào)試體驗也不會改變變量生命周期所以感知不到?？梢园?O0理解為“編譯器只做能不做就不做的保守翻譯”而不是“完全不翻譯”。3.2 什么時候該用 -O0除了日常調(diào)試還有兩類場景我強烈建議用-O0第一類是出問題需要精確復(fù)現(xiàn)現(xiàn)場時。比如線上程序崩潰你拉下來 Core Dump 文件這時候如果線上是-O2編譯的崩潰棧里好多函數(shù)參數(shù)都顯示optimized out排查效率極低。很多團(tuán)隊會在現(xiàn)場保留一份-O0的調(diào)試版本就是為了應(yīng)對這種問題。第二類是嵌入式裸機開發(fā)、外設(shè)寄存器操作多、時序要求嚴(yán)格的場景。寄存器寫操作和硬件行為強綁定編譯器但凡給你“聰明”一把比如把一個 volatile 讀操作優(yōu)化掉整個硬件驅(qū)動就廢了。雖然標(biāo)準(zhǔn)做法是給寄存器指針加上 volatile但在-O0下做初期功能驗證至少能少一層“編譯器替你亂搞”的風(fēng)險。4. -O1保守但不平庸的平衡點-O1常常被新手忽略因為大家都盯著-O2和-O3。但-O1在特定場景下非常有用尤其是編譯速度敏感型項目。-O1開啟的優(yōu)化主要包括死代碼消除DCE把永遠(yuǎn)不會執(zhí)行到的代碼分支刪掉。死存儲消除變量賦值后沒被讀編譯器直接不生成這個寫操作。局部公共子表達(dá)式消除CSE同一表達(dá)式在一個基本塊內(nèi)重復(fù)計算多次時只算一次。分支預(yù)測優(yōu)化根據(jù)靜態(tài)信息調(diào)整 if/else 排列讓大概率走的分支更緊湊。部分寄存器分配基礎(chǔ)優(yōu)化減少不必要的內(nèi)存讀寫。這些優(yōu)化有個共同特征它們不會改變程序的可觀察行為而且在絕大多數(shù)架構(gòu)上都是純賺不虧。不需要做復(fù)雜的跨函數(shù)分析也不會引入激進(jìn)變換所以編譯速度損失不大運行時收益卻很明顯。我有一個實際經(jīng)驗一個編譯需要 10 分鐘的大型 C 項目用-O1比用-O2編譯時間能縮短 25% 左右運行性能也就差 10%~15%。在持續(xù)集成CI流程里如果每次提交都要跑大量單元測試用-O1編譯測試版本能顯著減少等待時間而且測試結(jié)果比-O0更接近線上行為。4.1 -O1 適合誰做腳本語言解釋器、即時編譯器這類重編譯速度不重運行速度的項目。大項目 CI 流水線的中間產(chǎn)物。需要在老機器上、內(nèi)存吃緊的構(gòu)建環(huán)境中編譯的場景。5. -O2默認(rèn)的王者生產(chǎn)環(huán)境的標(biāo)配如果你問我剛?cè)肼氁患夜灸玫揭粋€未知項目該怎么編譯我會毫不猶豫告訴你先試-O2。絕大多數(shù)企業(yè)級 C/C 項目的 Release 版本都用-O2這是行業(yè)默認(rèn)值。-O2在-O1基礎(chǔ)上增加的核心優(yōu)化包括函數(shù)內(nèi)聯(lián)inlining被頻繁調(diào)用的小函數(shù)直接把函數(shù)體“展開”到調(diào)用處省去 call/ret 的開銷。循環(huán)展開把循環(huán)體復(fù)制多份減少循環(huán)控制語句執(zhí)行次數(shù)。全局公共子表達(dá)式消除不止在局部跨塊、跨循環(huán)都要消除重復(fù)計算。更激進(jìn)的寄存器分配盡可能把變量放進(jìn)寄存器而不是棧里。指令調(diào)度與重排讓 CPU 流水線更順暢地執(zhí)行指令。尾部調(diào)用優(yōu)化把遞歸調(diào)用變成循環(huán)棧復(fù)用。這些優(yōu)化的綜合效果非?？捎^。我做過一次實測后面會放數(shù)據(jù)一段包含矩陣乘法和字符串處理的代碼-O2比-O0快 3~5 倍而且編譯時間增加只有 2 倍左右性價比極高。5.1 為什么生產(chǎn)環(huán)境偏偏選中 -O2這里面有一個關(guān)鍵因素實踐經(jīng)驗的積累。-O3帶來的很多激進(jìn)優(yōu)化在實際項目中偶爾會引入“編譯器優(yōu)化導(dǎo)致的 bug”比如浮點重排、順序假設(shè)變化。而-O2經(jīng)過十幾年的工程檢驗bug 已經(jīng)被磨得很少行為相對可預(yù)期。另一個因素是內(nèi)核和系統(tǒng)庫的默認(rèn)選項。Linux 內(nèi)核編譯默認(rèn)使用-O2新版內(nèi)核實際更復(fù)雜但大體在-O2附近glibc 官方推薦也是-O2。生態(tài)主流在哪大家跟著用遇到問題的概率最低。5.2 但 -O2 也有“坑”最典型的是一個 C 語言里的“時序陷阱”如果代碼里依賴了 int 溢出的行為或者依賴了有符號變量左移的行為-O2下的優(yōu)化可能會產(chǎn)生不一樣的結(jié)果。比如int func(int x) { int y x * 4; return y 2; }-O0下執(zhí)行可能是先乘法再移位-O2下編譯器直接優(yōu)化成return x;因為乘以 4 再除以 4 恒等于自身不考慮溢出的情況下。這個優(yōu)化本身沒問題但如果你原本希望通過移位完成某種比特操作、或者對溢出后的符號位做了假設(shè)那么優(yōu)化后的代碼就跟期望不一致了。解決辦法只有一個別依賴 undefined behavior未定義行為和 implementation-defined behavior實現(xiàn)定義行為。這是 C/C 里最核心的規(guī)矩后面我會專門講。6. -O3性能怪獸但請系好安全帶-O3是在-O2基礎(chǔ)上繼續(xù)增加優(yōu)化gcc 和 clang 的主要增量包括更多函數(shù)內(nèi)聯(lián)包括更大、更深層的函數(shù)也強塞進(jìn)調(diào)用處。自動向量化auto-vectorization把循環(huán)里的標(biāo)量運算轉(zhuǎn)化成 SIMD 指令比如 x86 的 SSE/AVX一次算 4 個或 8 個 float。更加激進(jìn)的循環(huán)變換循環(huán)交換、循環(huán)展開、循環(huán)合并等。預(yù)測性函數(shù)內(nèi)聯(lián)編譯器根據(jù)熱路徑估計自動擴(kuò)大內(nèi)聯(lián)范圍?？邕^程優(yōu)化IPA跨文件、跨函數(shù)做全局?jǐn)?shù)據(jù)流分析。-O3在數(shù)值密集型計算里的收益尤其顯著。比如矩陣乘法、信號處理、圖像濾鏡用上自動向量化之后能再快 20%~50%。而且現(xiàn)代編譯器的向量化能力一年比一年強這份收益還在上升。但是-O3也有明顯的代價和風(fēng)險編譯時間暴漲。我自己編譯過一個包含大量模板的 C 項目-O3比-O2編譯時間增加了 80%。代碼體積變大。內(nèi)聯(lián)和循環(huán)展開意味著更多機器指令緩存壓力可能抵消性能收益。更激進(jìn)的浮點變換。比如把a*b a*c優(yōu)化成a*(bc)雖然代數(shù)上相等但浮點運算的舍入誤差不同結(jié)果最后幾位可能有差異。自動向量化引入的潛在越界問題。有些循環(huán)在邊界處理上原本依賴“多算一次”但不會出錯向量化后可能在邊界處多讀了幾個字節(jié)引發(fā)崩潰。6.1 什么時候放心用 -O3純數(shù)值計算程序沒有強 I/O、沒有系統(tǒng)調(diào)用密集邏輯、沒有依賴未定義行為的代碼。對性能有硬指標(biāo)要求的模塊比如視頻編解碼器、物理引擎。不介意調(diào)試?yán)щy且測試用例覆蓋充分。6.2 什么時候別用 -O3嵌入式裸機程序Flash 放不下。網(wǎng)絡(luò)協(xié)議棧、通信模塊對時序敏感且對代碼行為確定性要求極高。大量使用遞歸或鏈表指針跳轉(zhuǎn)的程序。這類程序難以向量化-O3收益不大編譯時間倒是實實在在增加了。7. -Os把“瘦身”進(jìn)行到底單片機開發(fā)者對-Os應(yīng)該不陌生。-Os的核心目標(biāo)是生成最小體積的機器碼它會基于-O2的優(yōu)化集合作調(diào)整凡是會導(dǎo)致代碼變大的優(yōu)化都會被壓制或削弱。典型區(qū)別函數(shù)內(nèi)聯(lián)只在被調(diào)函數(shù)極小且調(diào)用次數(shù)不多時才會執(zhí)行。循環(huán)展開通常被禁用因為展開通常意味著代碼變多。公共子表達(dá)式消除照做因為它通常能減少計算但未必增大體積。優(yōu)先選擇體積更小的指令序列哪怕稍慢一點。實際效果有多大我做過一次 Cortex-M 內(nèi)核的裸機程序?qū)Ρ韧环荽a-O2生成 28 KB-Os生成 21 KB體積減小了 25%運行時間只多出 3% 左右。這對于 Flash 只有 64 KB 的 MCU 來說絕對是救命級的選擇。7.1 -Os 的隱蔽缺陷代碼小了但有個問題容易被忽略部分“空間換時間”的優(yōu)化被關(guān)閉后程序?qū)χ袛囗憫?yīng)時間的波動會更敏感。在一些有硬實時的場景比如電機控制、電力電子你要搞清楚項目到底對“確定性”的要求有多高。另外調(diào)試器配合-Os會很難用——變量被復(fù)用和重排的情況比-O2更嚴(yán)重因為編譯器為了省空間會把一個棧槽反復(fù)用于多個變量。所以用-Os做 Release用-O0做 Debug這條原則千萬不能變。8. -Og一個折中的“調(diào)試友好優(yōu)化”很多開發(fā)者在-O2下遇到 bug硬著頭皮用 gdb 看匯編一點一點摳效率極低。-Og就是為這個場景設(shè)計的在優(yōu)化和調(diào)試體驗之間取一個中間值。-Og做了-O1級別的優(yōu)化但只選擇那些不太影響調(diào)試體驗的優(yōu)化項。比如它仍然會做死代碼消除但不會做破壞調(diào)試信息的寄存器重映射和重排。在-Og下編譯的程序斷點、單步、變量查看的體驗接近-O0而性能又比-O0好不少。我現(xiàn)在的個人習(xí)慣是開發(fā)中期用-Og替代-O0。前期功能還沒寫完邏輯頻繁改動用-O0進(jìn)入聯(lián)調(diào)和 bug 修復(fù)期改-Og既接近最終 Release 的行為又能保持不錯的調(diào)試體驗兩邊兼顧。9. 實測數(shù)據(jù)同一段代碼不同等級的差距說再多理論不如看數(shù)據(jù)。我寫了一段綜合的小型 benchmark包含矩陣乘法、快速排序、字符串哈希和遞歸斐波那契在 x86-64 Ubuntu gcc 12 下編譯運行記錄編譯時間和運行時間取 10 次平均值代碼體積用size命令查看。優(yōu)化等級編譯時間運行時間可執(zhí)行文件體積-O00.42s4.87s34 KB-O10.55s2.10s28 KB-O20.78s1.13s30 KB-O31.62s0.86s45 KB-Os0.72s1.52s22 KB-Og0.61s2.41s27 KB幾個關(guān)鍵結(jié)論-O2相比-O0快了 4.3 倍這個數(shù)字完全不夸張。-O3比-O2快約 24%但編譯時間翻了一倍多。遞歸斐波那契這種簡單遞歸函數(shù)-O3幾乎沒優(yōu)勢自動向量化幫不上忙但在矩陣乘法部分-O3的優(yōu)勢就體現(xiàn)出來了。-Os體積最小運行時間比-O2慢約 35%但體積少了 27%。所以說“我該用哪個優(yōu)化等級”沒有標(biāo)準(zhǔn)答案取決于瓶頸是 CPU、是二進(jìn)制體積、還是編譯時間。這也是為什么大型項目通常會讓構(gòu)建系統(tǒng)允許你隨時切換優(yōu)化等級參數(shù)的。10. 優(yōu)化和未定義行為90% 的“編譯器優(yōu)化 bug”真相說一個我這些年來一直被問的問題“老師我的程序在 -O2 下崩了在 -O0 下好好的是不是編譯器有 bug”我的回答永遠(yuǎn)是極少數(shù)情況是編譯器 bug95% 的可能是你的代碼觸碰了未定義行為UB, undefined behavior。C 和 C 標(biāo)準(zhǔn)里有一堆“雷區(qū)”操作標(biāo)準(zhǔn)沒有定義結(jié)果包括但不限于有符號整數(shù)溢出比如int x INT_MAX; x 1;。解引用空指針。數(shù)組越界訪問。讀取未初始化的變量。符合類型之間用memcpy之外的邏輯做強制轉(zhuǎn)換union 在某些場景下也算 UB。有符號整數(shù)左移溢出或移位次數(shù)超過類型位寬。在同一表達(dá)式里對一個變量先讀后寫且沒有序列點分隔如i i 1;。為什么-O0下這些代碼“看起來正常”因為-O0基本是機械翻譯你的匯編指令恰好做了你預(yù)期的事。但-O2下編譯器會根據(jù)“無 UB 的假設(shè)”做推導(dǎo)優(yōu)化。比如int func(int x) { if (x 1 x) { return 1; } return 0; }有符號整數(shù)x1x這個條件在標(biāo)準(zhǔn)語義下沒有任何一個x會成立如果x1溢出本身就是 UB編譯器假定不會發(fā)生所以編譯器直接把整個 if 分支刪了函數(shù)直接返回 0。你在-O0下還能看到那個分支存在但在-O2下它已經(jīng)蒸發(fā)了。這個例子在真實工程里經(jīng)常演化成一個防御性的邊界檢查被編譯器優(yōu)化沒了線上數(shù)據(jù)異常時沒攔住。怎么破三個方向代碼層面消除 UB有符號溢出改用無符號運算或__builtin_add_overflow這類內(nèi)建函數(shù)。使用 UBSanUndefinedBehaviorSanitizer在-O1或-O2下編譯時加-fsanitizeundefined程序會在觸發(fā) UB 時打印診斷信息。別跟編譯器較勁不要寫“靠具體機器的匯編行為活下來”的代碼跨平臺和跨優(yōu)化等級都會炸。順帶推薦 CS 愛好者必試的組合gcc -O2 -fsanitizeaddress,undefined -g -o app main.cAddressSanitizer 檢查內(nèi)存問題UndefinedBehaviorSanitizer 把關(guān)未定義行為。這兩兄弟在 CI 里加一道能擋掉 80% 的“神奇崩潰”。11. 工具鏈與實操怎么查編譯器實際做了哪些優(yōu)化選了某個優(yōu)化等級后你其實可以親眼看看編譯器到底對你的代碼做了什么。最直觀的方法是用-S參數(shù)生成匯編文件gcc -O2 -S main.c -o main.s然后打開main.s能看到優(yōu)化后的匯編。但人讀匯編效率太低我用得最多的是查 GCC 的優(yōu)化 dump 文件gcc -O2 -fdump-tree-all -c main.c -o main.o這個命令會生成一大堆.c.xxx文件記錄每一個優(yōu)化 pass 前后的中間表示。剛開始看會頭暈但配合diff對比不同 pass 的差異能看到變量什么時候被消除、表達(dá)式什么時候被折疊、循環(huán)什么時候被變換。這是理解“優(yōu)化在做什么”最好的教材。另一個實用的工具是-fopt-infogcc -O3 -fopt-info-vec -c matmul.c -o matmul.o如果編譯器對某個循環(huán)做了向量化終端會打印向量化的詳細(xì)信息。用它可以驗證你的代碼是否真的跑上了 SIMD是排查性能瓶頸的一把好手。12. 常見問題速查與我的個人建議最后整理一個速查表把日常被問得最多的問題統(tǒng)一回答問題答案程序在 -O2 崩潰在 -O0 正常是編譯器 bug 嗎先懷疑自己的 UB用 UBSan 檢查再懷疑編譯器為什么 gdb 里變量顯示 optimized out因為該變量已被優(yōu)化消失改用 -O0 或 -Og發(fā)布版本該用 -O2 還是 -O3默認(rèn) -O2數(shù)值密集且有完整測試再用 -O3Flash 不夠了怎么壓縮代碼用 -Os再配合 -ffunction-sections -fdata-sections 鏈接器 --gc-sections想快又不想可執(zhí)行文件太大-O2 是平衡點-Os 適合體積敏感的我的嵌入式中斷函數(shù)在 -O2 下失效了檢查是否漏了 volatile或用了不規(guī)范的寄存器訪問同一套代碼換了編譯器版本性能下降對比各版本優(yōu)化差異用 -fopt-info 查優(yōu)化決策再說兩個很多項目里都容易踩的具體坑?？右辉陬^文件里定義非 inline 函數(shù)。-O2下編譯器自動內(nèi)聯(lián)能掩蓋一部分問題但當(dāng)你切到-O0或者另一個編譯單元時多重定義鏈接錯誤立刻爆出來。解決方法是加static inline或者放到 .c 文件里定義、頭文件只放聲明?？佣裿olatile關(guān)鍵字當(dāng)成“什么都別優(yōu)化”的萬能藥。很多人看到某段寄存器代碼被優(yōu)化掉了第一反應(yīng)是加volatile。這確實能讓編譯器不再緩存本次讀取但volatile不保證原子性也不保證內(nèi)存屏障語義多線程下該崩還是崩。多線程同步要用的不是 volatile而是std::atomic/atomic_flag之類的原子原語。如果你是個剛接觸編譯優(yōu)化的開發(fā)者我建議按照這個順序來練習(xí)先用-O0寫功能保證邏輯對。切-O2跑測試發(fā)現(xiàn)差異。遇到優(yōu)化導(dǎo)致的問題用 UBSan/ASan 定位回頭改代碼。跑一遍-O3和-Os對比性能和體積理解取舍。再用-fopt-info和-S看匯編搞清楚編譯器每一分性能提升從哪來。這套流程走完你對 -O 優(yōu)化的理解會遠(yuǎn)超絕大多數(shù)“能編譯能運行就行”的同行。我在實際項目中體會最深的一點是編譯器優(yōu)化的本質(zhì)是“基于安全假設(shè)的大膽推導(dǎo)”。它敢刪代碼、敢重排語句、敢合并分支是因為它默認(rèn)你的代碼完全符合語言標(biāo)準(zhǔn)。只要你守住標(biāo)準(zhǔn)這層底線-O2 就是你最省心的朋友一旦越界它就是你最難纏的對手。從-O0到-Og再到-O2每一步都是你在“調(diào)試體驗、運行性能、代碼體積”三者之間的主動取舍——理解得越深這個取舍就越有價值。