Solidity Optimizer Under the Hood

Solidity 的優化器長期以來被開發者當作黑盒子使用——打開 `--optimize` 旗標，設一個很大的 runs 數字，然後期待 Gas 費用下降。這場演講的目標是揭開黑盒蓋子，說明優化器在兩條編譯管線中分別做了什麼事。

Solidity 提供兩種編譯路徑。Legacy 管線的流程相對直接：原始碼 → EVM assembly → 優化器作用於 assembly → bytecode。Via-IR 管線則多了一個中間層：原始碼先被翻譯成 Yul（一種精簡的結構化語言，具備函式、if 和 for，但沒有繼承、modifier 等高階語法糖），優化器在 Yul 層完成高階轉換後，才降轉為 EVM assembly，再執行一次 EVM 層的優化。目前預設仍是 Legacy 管線，但 Solidity 團隊計畫未來將 Via-IR 設為預設。Yul 的結構化控制流和明確的跳躍目標讓靜態分析更容易，也使跨函式的全域優化成為可能，同時它也是 Via-IR 能自動解決 `Stack too deep` 的根本原因。

在 EVM assembly 層，Peephole 優化器以滑動視窗掃描指令序列，尋找可用等價但更廉價指令替換的模式。乘以零直接輸出常數零、`PUSH` 後立刻 `POP` 整組刪除、兩次對調同一對堆疊元素合而為一、`ADDRESS` + `BALANCE` 合併為 `SELFBALANCE`——這些都是典型案例。更值得注意的是，優化器還會追蹤 storage 和 memory 在特定時間點的精確內容：當它確定 memory[0] 存放著 `0xFF` 且在雜湊之前沒有任何覆寫時，整個 Keccak256 運算會在編譯期直接完成，runtime bytecode 只剩一條 `PUSH32`。

Yul 優化器由多個 pass 串接而成，每個 pass 保持語意不變地對程式碼做轉換，且 pass 的執行順序至關重要——前一個 pass 建立的條件往往是後一個 pass 的前提。Load Resolver 偵測 storage/memory 的值是否已在堆疊上，若是則以 `DUP`/`SWAP` 重用而非重新 `SLOAD`，在同一變數多次使用的函式中可省下顯著的 Gas。Dead Code Eliminator 移除永遠不可能執行到的程式碼；值得注意的是，即使 `return` 位於加法之前，若加法不在 `unchecked` 區塊內，溢位檢查仍會保留——因為移除它會改變合約行為。Unused Store Eliminator 刪除對同一位置的早期寫入（若後續被覆寫前從未被讀取），但一旦中間存在外部呼叫，優化器必須保守假設對方可能讀取該 storage，因此不會刪除。Function Specializer 對以字面常數作為引數的呼叫點生成特化函式版本，有時能進一步觸發其他優化，但也可能膨脹 bytecode；開發者可用一個「混淆包裝函式」阻止特化，或在編譯器輸入中移除該 pass。

歷史上優化器確實引入過真實的 Bug。第一個出現在 Unused Store Eliminator：若函式先寫入 storage，再呼叫一個含有 inline assembly `return`（直接結束整個 call 而非僅返回函式）的子函式，接著在正常執行路徑再次寫入同一 slot，優化器會誤判第一次寫入為死寫入並刪除；然而 assembly `return` 路徑根本不會執行到第二次寫入，導致 storage 狀態與預期不符。第二個 Bug 同樣源於 Unused Store Eliminator：跨越兩個 inline assembly 區塊的硬編碼記憶體偏移量讀寫被判定為無關，第一個區塊的 `mstore` 遭刪除，第二個區塊讀到的是未初始化或被暫存空間汙染的值。

演講最後強調：優化器是一組定義明確的轉換規則，而非魔法。它能移除多餘的 opcode、合併等價指令、預計算常數結果，但它無法替代好的演算法設計——將 O(n²) 的迴圈降為常數時間，這件事始終是開發者的責任。