三大 AI 巨頭 OpenAI、Google、Meta 組團發布自家大模型最新研究成果 ——

OpenAI 推出基于 GPT-4 訓練的專門找 bug 的新模型 CriticGPT，谷歌開源 9B、27B 版 Gemma2，而 Meta 則拿出了一項最新的人工智能突破 ——LLM Compiler。

這是一套強大的開源模型，旨在優化代碼并徹底改變編譯器設計。這項創新有可能改變開發者處理代碼優化的方式，使其更快、更高效、更經濟。

據悉，該 LLM Compiler 的優化潛力達到了自動調優搜索的 77%，這一結果可以顯著減少編譯時間，并提高各種應用的代碼效率，并且在反匯編方面，其往返反匯編的成功率為 45%。

有網友表示，這像是代碼優化和反匯編的游戲規則改變者。

這對于開發者來說是個讓人難以置信的好消息。

概述

大語言模型在眾多軟件工程和編程任務中表現出了卓越的能力，然而它們在代碼優化及編譯器領域的應用尚未得到充分挖掘。訓練這些 LLMs 需要消耗大量的計算資源，包括昂貴的 GPU 時間和龐大的數據集，這往往使得許多研究和項目難以為繼。

為了彌補這一空白，Meta 研究團隊引入了一種 LLM Compiler，以專門優化代碼并徹底改變編譯器設計。通過在包含 5460 億個標記的 LLVM-IR 和匯編代碼的龐大語料庫上訓練模型，他們使模型能夠理解編譯器中間表示、匯編語言和優化技術。

論文鏈接：https://ai.meta.com/research/publications/meta-large-language-model-compiler-foundation-models-of-compiler-optimization/

研究人員在他們的論文中解釋說：「LLM Compiler 增強了對編譯器中間表示（IR）、匯編語言和優化技術的理解。」這種增強的理解使模型能夠執行以前僅限于人類專家或專業工具的任務。

LLM Compiler 的訓練流程如圖 1 所示。

LLM Compiler 在代碼大小優化方面取得了顯著成果。在測試中，模型的優化潛力達到了自動調優搜索的 77%，這一結果可以顯著減少編譯時間，并提高各種應用的代碼效率。

模型在反匯編方面的能力更為出色。LLM Compiler 在將 x86_64 和 ARM 匯編代碼轉換回 LLVM-IR 時，往返反匯編的成功率為 45%（其中 14% 完全匹配）。這種能力對于逆向工程任務和舊代碼維護可能具有無法估量的價值。

項目的核心貢獻者之一 Chris Cummins 強調了這項技術的潛在影響：「通過提供兩種大小的預訓練模型（7 億和 13 億參數）并通過微調版本展示其有效性，」他說，「LLM Compiler 為探索 LLM 在代碼和編譯器優化領域未被開發的潛力鋪平了道路。」

用于編譯器優化的 Code Llama

在匯編代碼和編譯器 IR 上進行預訓練

用于訓練編程 LLMs 的數據通常主要由像 Python 這樣的高級源語言組成，匯編代碼在這些數據集中的比例微乎其微，編譯器 IR 的比例更小。

為了構建一個對這些語言有良好理解的 LLM，研究團隊用 Code Llama 的權重初始化 LLM Compiler 模型，然后在一個以編譯器為中心的數據集上訓練 4010 億個 token，這個數據集主要由匯編代碼和編譯器 IR 組成，如表 1 所示。

數據集 LLM Compiler 主要在由 LLVM（版本 17.0.6）生成的編譯器中間表示和匯編代碼上進行訓練，這些數據來源于用于訓練 Code Llama 的同一數據集，已在表 2 中概述了該數據集。與 Code Llama 一樣，我們也從自然語言數據集中獲取少量訓練批次。

編譯器模擬的指令微調

為了理解代碼優化的機制，研究團隊對 LLM Compiler 模型進行指令微調，以模擬編譯器優化，如圖 2 所示。

其思路是從有限的未優化種子程序集合中，通過對這些程序應用隨機生成的編譯器優化序列，生成大量示例。然后他們訓練模型預測優化生成的代碼，還訓練模型預測應用優化后的代碼大小。

任務規范。給定未經優化的 LLVM-IR（由 clang 前端輸出），一個優化過程列表，以及一個起始代碼大小，生成應用這些優化后的結果代碼以及代碼大小。

這個任務有兩種類型：在第一種中，模型預期輸出編譯器 IR；在第二種中，模型預期輸出匯編代碼。兩種類型的輸入 IR、優化過程和代碼大小是相同的，提示決定了所需的輸出格式。

代碼大小。他們使用兩個指標來衡量代碼大小：IR 指令數和二進制大小。二進制大小通過將 IR 或匯編降級為目標文件后，.TEXT 和 .DATA 段大小的總和計算得出。我們排除 .BSS 段，因為它不影響磁盤上的大小。

優化 pass。在這項工作中，研究團隊針對 LLVM 17.0.6，并使用新的過程管理器 (PM, 2021)，它將 pass 分類為不同的級別，如模塊、函數、循環等，以及轉換和分析 pass 。轉換 pass 改變給定的輸入 IR，而分析 pass 生成影響后續轉換的信息。

在 opt 的 346 個可能的 pass 參數中，他們選擇了 167 個使用。這包括每個默認優化流水線 (例如 module (default<Oz>))，單獨的優化轉換 pass (例如 module (constmerge))，但排除了非優化實用程序 pass (例如 module (dot-callgraph)) 和不保留語義的轉換 pass (例如 module (internalize))。

他們排除了分析 pass，因為它們沒有副作用，我們依賴 pass 管理器根據需要注入依賴的分析 pass。對于接受參數的 pass，我們使用默認值 (例如 module (licm<allowspeculation>))。表 9 包含了所有使用的 pass 列表。我們使用 LLVM 的 opt 工具應用 pass 列表，并使用 clang 將結果 IR 降級為目標文件。清單 1 顯示了使用的命令。

數據集。研究團隊通過對表 2 中總結的未優化程序應用 1 到 50 個隨機優化 pass 列表生成編譯器模擬數據集。每個 pass 列表的長度是均勻隨機選擇的。pass 列表是通過從上述 167 個 pass 集合中均勻采樣生成的。導致編譯器崩潰或在 120 秒后超時的 pass 列表被排除。

LLM Compiler FTD ：擴展下游編譯任務 

優化標志調優的指令微調

操作編譯器標志對運行時性能和代碼大小都有顯著影響。研究團隊訓練 LLM Compiler FTD 模型執行下游任務，即為 LLVM 的 IR 優化工具 opt 選擇標志，以生成最小的代碼大小。

標志調優的機器學習方法以前已經顯示出良好的結果，但在不同程序之間的泛化方面存在困難。以前的工作通常需要編譯新程序數十或數百次，以嘗試不同的配置并找出性能最佳的選項。該研究團隊通過預測標志來最小化未見程序的代碼大小，在這個任務的零樣本版本上訓練和評估 LLM Compiler FTD 模型。

他們的方法不依賴于所選擇的編譯器和優化指標，他們打算在未來針對運行時性能。目前，優化代碼大小簡化了訓練數據的收集。

任務規范。研究團隊向 LLM Compiler FTD 模型呈現一個未優化的 LLVM-IR (由 clang 前端生成)，并要求它生成應該應用的 opt 標志列表，這些優化應用前后的二進制大小，以及輸出代碼，如果無法對輸入代碼進行改進，則生成一個只包含未優化二進制大小的簡短輸出消息。

他們使用了與編譯器模擬任務相同的受限優化 pass 集，并以相同的方式計算二進制大小。

圖 3 說明了用于生成訓練數據的過程以及如何在推理時使用模型。

在評估時只需要生成的 pass 列表。他們從模型輸出中提取 pass 列表，并使用給定的參數運行 opt。然后，研究人員可以評估模型預測的二進制大小和優化輸出代碼的準確性，但這些是輔助學習任務，不是使用所必需的。

正確性。LLVM 優化器并非無懈可擊，以意外或未經測試的順序運行優化 pass 可能會暴露出微妙的正確性錯誤，從而降低模型的實用性。為了緩解這種風險，研究團隊開發了 PassListEval，這是一個工具，用于幫助自動識別破壞程序語義或導致編譯器崩潰的 pass 列表。圖 4 顯示了該工具的概覽。

PassListEval 接受候選 pass 列表作為輸入，并在一個包含 164 個自測試 C++ 程序的套件上對其進行評估，這些程序取自 HumanEval-X。每個程序都包含一個編程挑戰的參考解決方案，例如「檢查給定數字向量中是否有兩個數字之間的距離小于給定閾值」，以及驗證正確性的單元測試套件。他們將候選 pass 列表應用于參考解決方案，然后將它們與測試套件鏈接以生成二進制文件。執行時，如果任何測試失敗，二進制文件將崩潰。如果任何二進制崩潰，或者任何編譯器調用失敗，我們就拒絕該候選 pass 列表。

數據集。該團隊在一個源自 450 萬個未優化 IR 的標志調優示例數據集上訓練了 LLM Compiler FTD 模型，這些 IR 用于預訓練。為生成每個程序的最佳 pass 列表示例，他們進行了廣泛的迭代編譯過程，如圖 3 所示。

1. 研究團隊使用大規模隨機搜索為程序生成初始候選最佳 pass 列表。對每個程序，他們獨立生成最多 50 個 pass 的隨機列表，從之前描述的 167 個可搜索 pass 集合中均勻采樣。每次他們評估一個程序的 pass 列表時，都記錄生成的二進制大小，然后選擇產生最小二進制大小的每個程序 pass 列表。他們運行了 220 億次獨立編譯，平均每個程序 4,877 次。

2. 隨機搜索生成的 pass 列表可能包含冗余 pass，這些 pass 對最終結果沒有影響。此外，一些 pass 順序是可交換的，重新排序不會影響最終結果。由于這些會在訓練數據中引入噪聲，他們開發了一個最小化過程，并將其應用于每個 pass 列表。

最小化包括三個步驟：冗余 pass 消除、冒泡排序和插入搜索。在冗余 pass 消除中，他們通過迭代刪除單個 pass 來最小化最佳 pass 列表，看它們是否對二進制大小有貢獻，如果沒有，就丟棄它們。重復此過程，直到不能再丟棄 pass。然后冒泡排序嘗試為 pass 子序列提供統一排序，根據關鍵字對 pass 進行排序。最后，插入排序通過遍歷 pass 列表中的每個 pass 并嘗試在其之前插入 167 個搜索 pass 中的每一個來執行局部搜索。如果這樣做改善了二進制大小，就保留這個新的 pass 列表。整個最小化管道循環直到達到固定點。最小化后的 pass 列表長度分布如圖 9 所示。平均 pass 列表長度為 3.84。

3. 他們將之前描述過 PassListEval 應用于候選最佳 pass 列表。通過這種方式，他們確定了 1,704,443 個獨立 pass 列表中的 167,971 個 (9.85%) 會導致編譯時或運行時錯

4. 他們將 100 個最常見的最優 pass 列表廣播到所有程序，如果發現改進就更新每個程序的最佳 pass 列表。之后，唯一最佳 pass 列表的總數從 1,536,472 減少到 581,076。

上述自動調優管道相比 -Oz 產生了 7.1% 的幾何平均二進制大小減少。圖 10 顯示了單個 pass 的頻率。對他們來說，這種自動調優作為每個程序優化的黃金標準。雖然發現的二進制大小節省很顯著，但這需要 280 億次額外編譯，計算成本超過 21,000 個 CPU 天。對 LLM Compiler FTD 進行指令微調以執行標志調優任務的目標是在不需要運行編譯器數千次的情況下達到自動調優器性能的一部分。

 反匯編的指令微調

將代碼從匯編語言提升到更高層次的結構，可以運行額外的優化，例如直接集成到應用程序代碼中的庫代碼，或者將遺留代碼移植到新架構。反編譯領域在將機器學習技術應用于從二進制可執行文件生成可讀和準確的代碼方面取得了進展。在本研究中，研究團隊展示了 LLM Compiler FTD 如何通過微調進行反匯編，學習匯編代碼和編譯器 IR 之間的關系。任務是學習 clang -xir - -o - -S 的逆向翻譯，如圖 5 所示。

往返測試。使用 LLM 進行反匯編會導致正確性問題。提升的代碼必須通過等價性檢查器進行驗證，這并不總是可行的，或者需要手動驗證正確性，或經過充分的測試用例以獲得信心。然而，可以通過往返測試找到正確性的下限。也就是說，通過將提升的 IR 重新編譯成匯編代碼，如果匯編代碼是相同的，則 IR 是正確的。這為使用 LLM 的結果提供了一條簡單途徑，并且是衡量反匯編模型效用的一種簡單方法。

任務規范。研究團隊向模型提供匯編代碼，并訓練它發出相應的反匯編 IR。這項任務的上下文長度設置為輸入匯編代碼 8k 個 token 和輸出 IR8k 個 token。

數據集。他們從之前任務中使用的數據集中派生出匯編代碼和 IR 對。他們的微調數據集包含 470 萬個樣本，輸入 IR 在降低到 x86 匯編之前已經使用 - Oz 進行了優化。

訓練參數 

數據通過字節對編碼進行標記化，使用與 Code Llama、Llama 和 Llama 2 相同的標記器。他們對所有四個訓練階段使用相同的訓練參數。他們使用的大部分訓練參數與 Code Llama 基礎模型相同，使用 AdamW 優化器，β1 和 β2 的值為 0.9 和 0.95。他們使用余弦調度，預熱步驟為 1000 步，并將最終學習率設置為峰值學習率的 1/30。

與 Code Llama 基礎模型相比，該團隊將單個序列的上下文長度從 4096 增加到 16384，但保持批量大小恒定為 400 萬個 token。為了適應更長的上下文，他們將學習率設置為 2e-5，并修改了 RoPE 位置嵌入的參數，其中他們將頻率重置為基本值 θ=10^6。這些設置與 Code Llama 基礎模型進行的長上下文訓練一致。

 評估

該研究團隊評估 LLM Compiler 模型在標志調優和反匯編任務、編譯器模擬、下一個 token 預測以及軟件工程任務上的表現。

標志調優任務

方法。他們評估 LLM Compiler FTD 在未見程序的優化標志調優任務上的表現，并與 GPT-4 Turbo 和 Code Llama - Instruct 進行比較。他們對每個模型運行推理，從模型輸出中提取優化 pass 列表，然后他們使用這個 pass 列表來優化特定程序并記錄二進制大小，基線是使用 -Oz 優化時程序的二進制大小。

對于 GPT-4 Turbo 和 Code Llama - Instruct，他們在提示后附加一個后綴，提供額外上下文以進一步描述問題和預期輸出格式。

所有模型生成的 pass 列表都使用 PassListEval 進行驗證，如果驗證失敗則使用 -Oz 作為替代。為進一步驗證模型生成的 pass 列表的正確性，他們鏈接最終的程序二進制文件，并將其輸出與使用保守的 -O2 優化管道優化的基準輸出進行差分測試。

數據集。研究團隊使用從 MiBench 基準套件提取的 2,398 個測試提示進行評估。為生成這些提示，他們取構成 24 個 MiBench 基準的所有 713 個翻譯單元，并從每個單元生成未優化的 IR，然后將它們格式化為提示。如果生成的提示超過 15k tokens，他們使用 llvm-extract 將代表該翻譯單元的 LLVM 模塊分割成更小的模塊，每個函數一個，這導致 1,985 個提示適合 15k token 上下文窗口，剩下 443 個翻譯單元不適合。在計算性能分數時，他們對 443 個被排除的翻譯單元使用 -Oz。表 10 總結了基準。

結果。表 3 顯示了所有模型在標志調優任務上的零樣本性能。只有 LLM Compiler FTD 模型比 -Oz 有所改進，13B 參數模型略優于較小的模型，在 61% 的情況下生成比 -Oz 更小的目標文件。

在某些情況下，模型生成的 pass 列表導致比 -Oz 更大的目標文件大小。例如，LLM Compiler FTD 13B 在 12% 的情況下有退化。這些退化可以通過簡單地編譯程序兩次來避免：一次使用模型生成的 pass 列表，一次使用 -Oz，然后選擇產生最佳結果的 pass 列表。通過消除相對于 -Oz 的退化，這些 -Oz 備份分數將 LLM Compiler FTD 13B 相對于 -Oz 的總體改進提高到 5.26%，并使 Code Llama - Instruct 和 GPT-4 Turbo 相對于 -Oz 有適度的改進。圖 6 顯示了每個模型在各個基準上的性能細分。

 二進制大小準確性。雖然模型生成的二進制大小預測對實際編譯沒有影響，但研究團隊可以評估模型在預測優化前后的二進制大小方面的性能，以了解每個模型對優化的理解程度。圖 7 顯示了結果。

LLM Compiler FTD 的二進制大小預測與實際情況相關性良好，7B 參數模型對未優化和優化的二進制大小分別達到了 0.083 和 0.225 的 MAPE 值。13B 參數模型的 MAPE 值相似，分別為 0.082 和 0.225。Code Llama - Instruct 和 GPT-4 Turbo 的二進制大小預測與實際情況幾乎沒有相關性。研究人員注意到，LLM Compiler FTD 對優化代碼的錯誤略高于未優化代碼。特別是 LLM Compiler FTD 偶爾有高估優化效果的趨勢，導致預測的二進制大小低于實際情況。

消融研究。表 4 對模型在 500 個提示的小型保留驗證集上的性能進行了消融研究，這些提示來自與他們訓練數據相同的分布 (但未在訓練中使用)。他們在圖 1 所示訓練管道的每個階段進行標志調優訓練，以比較性能。如圖所示，反匯編訓練導致性能從平均 5.15% 略微下降到 5.12%(相對于 -Oz 的改進)。他們還展示了用于生成第 2 節所述訓練數據的自動調優器的性能。LLM Compiler FTD 達到了自動調優器 77% 的性能。

 反匯編任務

方法。研究團隊評估 LLM 生成的代碼在將匯編代碼反匯編到 LLVM-IR 時的功能正確性。他們評估 LLM Compiler FTD 并與 Code Llama - Instruct 和 GPT-4 Turbo 進行比較，發現需要額外的提示后綴才能從這些模型中提取最佳性能。

后綴提供了關于任務和預期輸出格式的額外上下文。為評估模型的性能，他們將模型生成的反匯編 IR 往返降級回匯編。這使我們能夠通過比較原始匯編與往返結果的 BLEU 分數來評估反匯編的準確性。從匯編到 IR 的無損完美反匯編將有 1.0 的往返 BLEU 分數 (精確匹配)。

數據集。他們使用從 MiBench 基準套件提取的 2,015 個測試提示進行評估，取用于上述標志調優評估的 2,398 個翻譯單元，生成反匯編提示。然后他們根據最大 8k token 長度過濾提示，允許 8k tokens 用于模型輸出，剩下 2,015 個。表 11 總結了基準。

結果。表 5 顯示了模型在反匯編任務上的性能。

LLM Compiler FTD 7B 的往返成功率略高于 LLM Compiler FTD 13B，但 LLM Compiler FTD 13B 具有最高的往返匯編準確性 (往返 BLEU) 和最頻繁產生完美反匯編 (往返精確匹配)。Code Llama - Instruct 和 GPT-4 Turbo 在生成語法正確的 LLVM-IR 方面存在困難。圖 8 顯示了所有模型的往返 BLEU 分數分布。

消融研究。表 6 對模型在 500 個提示的小型保留驗證集上的性能進行了消融研究，這些提示取自之前使用的 MiBench 數據集。

他們在圖 1 所示訓練管道的每個階段進行反匯編訓練，以比較性能。往返率在通過整個訓練數據堆棧時最高，并隨每個訓練階段持續下降，盡管往返 BLEU 在每個階段變化不大。

 基礎模型任務

方法。該研究團隊在下一個 token 預測和編譯器模擬兩個基礎模型任務上對 LLM Compiler 模型進行消融研究。他們在訓練管道的每個階段進行這種評估，以了解為每個連續任務訓練如何影響性能。對于下一個 token 預測，他們在所有優化級別的 LLVM-IR 和匯編代碼的小樣本上計算困惑度。他們使用兩個指標評估編譯器模擬：生成的 IR 或匯編代碼是否編譯，以及生成的 IR 或匯編代碼是否與編譯器產生的完全匹配。

數據集。對于下一個 token 預測，他們使用從與我們訓練數據相同分布但未用于訓練的小型保留驗證數據集。他們使用混合的優化級別，包括未優化代碼、用 -Oz 優化的代碼和隨機生成的 pass 列表。對于編譯器模擬，他們使用從 MiBench 生成的 500 個提示進行評估，這些提示使用第 2.2 節描述的方式隨機生成的 pass 列表。

結果。表 7 顯示了 LLM Compiler FTD 在所有訓練階段在兩個基礎模型訓練任務 (下一個 token 預測和編譯器模擬) 上的性能。下一個 token 預測性能在 Code Llama 之后急劇上升，后者幾乎沒有見過 IR 和匯編，并在隨后的每個微調階段略有下降。

對于編譯器模擬，Code Llama 基礎模型和預訓練模型表現不佳，因為它們沒有在這個任務上訓練過。在編譯器模擬訓練之后直接達到最高性能，其中 LLM Compiler FTD 13B 生成的 95.6% 的 IR 和匯編可以編譯，20% 與編譯器完全匹配。在進行標志調優和反匯編微調后，性能下降。

軟件工程任務

方法。雖然 LLM Compiler FTD 的目的是為代碼優化提供基礎模型，但它建立在為軟件工程任務訓練的基礎 Code Llama 模型之上。為評估 LLM Compiler FTD 的額外訓練如何影響代碼生成的性能，他們使用與 Code Llama 相同的基準套件，評估 LLM 從自然語言提示生成 Python 代碼的能力，如「編寫一個函數，找出可以從給定的對集合形成的最長鏈。」

數據集。他們使用 HumanEval 和 MBPP 基準，與 Code Llama 相同。

結果。表 8 顯示了從 Code Llama 基礎模型開始的所有模型訓練階段和模型大小的貪婪解碼性能 (pass@1)。它還顯示了模型在 pass@10 和 pass@100 上的分數，這些分數是用 p=0.95 和 temperature=0.6 生成的。每個以編譯器為中心的訓練階段都導致 Python 編程能力略有退化。在 HumanEval 和 MBPP 上，LLM Compiler 的 pass@1 性能最多下降 18% 和 5%，LLM Compiler FTD 在額外的標志調優和反匯編微調后最多下降 29% 和 22%。所有模型在這兩個任務上仍然優于 Llama 2。

局限性

Meta 研究團隊已經展示了 LLM Compiler 在編譯器優化任務上表現良好，并且相比先前的工作，對編譯器表示和匯編代碼的理解有所改進，但仍存在一些局限性。主要限制是輸入的有限序列長度 (上下文窗口)。

LLM Compiler 支持 16k tokens 的上下文窗口，但程序代碼可能遠遠超過這個長度。例如，當格式化為標志調優提示時，67% 的 MiBench 翻譯單元超過了這個上下文窗口，如表 10 所示。

為了緩解這一問題，他們將較大的翻譯單元拆分為單獨的函數，盡管這限制了可以執行的優化范圍，而且仍有 18% 的拆分翻譯單元對模型來說太大，無法作為輸入接受。研究人員正在采用不斷增加的上下文窗口，但有限的上下文窗口仍然是 LLM 的一個普遍問題。

第二個限制，也是所有 LLM 的共同問題，是模型輸出的準確性。建議 LLM Compiler 的用戶使用特定于編譯器的評估基準來評估他們的模型。鑒于編譯器并非無 bug，任何建議的編譯器優化都必須經過嚴格測試。當模型反編譯匯編代碼時，其準確性應通過往返、人工檢查或單元測試來確認。對于某些應用，LLM 生成可以被限制在正則表達式內，或與自動驗證相結合以確保正確性。