RFC-0151:CPU 指定專用的編譯器調整標記 | |
---|---|
狀態 | 已接受 |
區域 |
|
說明 | 針對用來管理 CPU 指定功能的編譯器旗標,以及這些功能對平台和 SDK 建構的影響提出修改建議。 |
問題 | |
變更 | |
作者 | |
審查人員 | |
提交日期 (年/月) | 2022-01-04 |
審查日期 (年/月) | 2022-02-02 |
摘要
針對用來管理 CPU 指定功能的編譯器旗標,以及這些功能對平台和 SDK 建構的影響提出修改建議。
提振精神
Fuchsia 建構會產生許多構件,當中包含不同架構的可執行機器程式碼。例如:預先建構且發布為 SDK 的共用程式庫,或是平台和產品系統映像檔中包含的可執行 C/C++ 或 Rust 二進位檔。在編譯器中產生機器程式碼時,請務必指出以下內容:
目標架構:要使用的指令集架構為何?例如 x86-64 或 AArch64 ISA。此外,編譯器也可以鎖定 ISA 的修訂版本。 修訂版本可能會針對現有操作說明提供額外指示或變化版本,例如新的浮點/SIMD 指令,或更寬的原子記憶體作業,藉此大幅改善效能。請務必瞭解目標架構,以便產生保證能在目標裝置上執行的程式碼。「提高」目標架構可提供新功能,但為了與舊硬體回溯相容。
上方:ARM ISA 進程 (資料來源)
目標微架構:ISA 是如何實作的?這通常以依序執行指示、是否要依順序執行操作說明、解碼頻寬、快取負載延遲等。指定目標微架構可讓編譯器產生在目標硬體上執行速度可能更快的機器程式碼,而不會限制硬體相容性。
上方:Intel Core 2 微架構區塊圖 (來源)
編譯器可讓使用者以稍後審查的方式指定這些目標。Fuchsia 的建構系統能夠針對全域或每個二進位檔設定編譯器。目前在 Fuchsia 版本中實作的 CPU 指定功能有一些缺點,而這個 RFC 旨在解決這些問題:
選擇 arm64 基準設定是以特定 CPU (Cortex-A53) 為指定目標,而非 ISA Plus 功能。這會導致定義不良的平台基準。
由於缺乏既有技術且沒有記錄的政策或最佳做法,我們無法為此基準設定覆寫。因此,Fuchsia 會建構全部但回到基準,包括指定明確不在基準範圍內的硬體的建構設定。
這些缺點自 2016 年成立以來就一直存在,在前一代的藝術發展至今。現在的系統是在第一台裝置上提供 Fuchsia (也就是採用與時日平台 arm64 基準相同的微架構)。
最近的發展指出現在該是完成整修。具體來說,除了指定 Cortex-A53 的 Astro 和 Sherlock 主機板外,Fuchsia 現在也支援 Nelson 板設定 (Cortex-A55) 和 Atlas 板設定 (Intel Amber Lake)。不過,這些版本目前並未經過設定,因此無法利用基準和實際目標之間的差異。
此外,我們也越來越有興趣修正或增加平台硬體基準的定義。若基準設定和特定主面板設定明確定義,相關工作就會加快。另請參閱:
為因應當前和未來的挑戰,這項 RFC 提議對建構作業中的 CPU 指定功能立即進行變更,以及政府在可預見的未來發展目標機制和政策。
相關人員
講師: cpu@google.com
審查者:
aaronwood@google.com
- 系統組裝digit@google.com
- 版本mcgrathr@google.com
- 核心mvanotti@google.com
- 安全性maniscalco@google.com
- 核心phosek@google.com
- 工具鍊travisg@google.com
- 核心
顧問:
由於提議的變更會影響平台上的大多數內容,因此所有提案都應根據諮詢結果自行評估。我特別歡迎圖像、媒體和 SDK 等團隊 提供意見回饋。
社群媒體化:
本提案的重點內容首次經過 60 分鐘的簡報,並於 Fuchsia 核心 Evolution Working Group (核心演變工作小組) 公開討論。
背景
編譯時間調整旗標
Fuchsia 使用 clang 來編譯 C/C++,部分 Fuchsia 程式碼子集也會使用 gcc 來持續建構及測試。這兩項工具都提供下列標記:
-march
:設定目標架構,例如執行個體 x86-64-v2
(目前符合 RFC-0073 的 x64 基準) 或 ARMv8-A。或者,您也可以指定其他架構功能,例如 +avx2
表示 Intel Haswell 擴充功能高於 x64 基準。
-mtune
:設定目標微架構,例如 cortex-a53
或 haswell
。在未使用 -mtune
和 -mcpu
時,這個值會設為 generic
,以指定特定 CPU 範圍中的平衡點。
-mcpu
:設定目標 CPU。接受的值類似 -mtune
。對於 ARM CPU,這相當於設定目標架構 (-march
) 和目標微架構 (-mtune
) 以符合目標 CPU。在 x86 上,這將視為已淘汰,因此指定的值會重新導向 -mtune
。
Rust 編譯器提供程式碼產生器選項,如下所示:
target-cpu
:與 -mcpu
類似,接受執行個體 cortex-a53
。
target-features
:與 -march
功能類似,例如 +avx2
。
目前狀態
目前所有 x64 版本都是使用 -march=x86-64-v2
編譯,且所有 ARM 版本都會使用 -mcpu=cortex-a53
編譯。
有一種機制可透過名為 board_configs
的 GN 引數覆寫這項設定,而 .gni
檔案中的主面板設定可覆寫該引數。部分主面板 (尤其是 Astro 和 Sherlock) 手動指定上述 Cortex-A53 設定,但目前這是免人工管理的設定,因為在未定義覆寫的情況下,系統會以相同設定做為備用設定。
大部分的主面板設定都未設定 board_configs
。
調整目標和權衡
本節將簡要說明設定 CPU 指定選項時應考量的不同目標,以及兩者之間的一些取捨。
硬體相容性:指定 ISA 先前的版本,使其與舊版硬體相容。更高的相容性會產生降低使用成本或安全性益處的全新 ISA 功能。
效能:新的指示可以提升效能:更快或更廣泛的原子作業、加速數學 (FPU、SIMD 改善)、常見演算法 (例如 CRC 和 AES) 的內建加速器。調整指定 CPU 的機器程式碼可產生在目標 CPU 上執行的程式碼更快執行速度,但通常也會犧牲目標參數外的其他 CPU 效能。
與二進位檔大小的互通性:系統已觀察到,在某些情況下會增加二進位檔大小,例如當指令排程最佳化的目標指定序列處理器時,會增加登錄壓力。
二進位檔大小:使用特定 CPU 功能解鎖部分 Codegen 功能。例如,SIMD 會啟用自動向量,這與循環解除類似,效果會更快產生程式碼,同時更大。針對順序內 CPU 調整指示的排程通常會產生更大的程式碼,因為這樣會新增更多排程限制,並可能增加暫存器壓力及註冊溢出。
其他 Codegen 功能可能會減少二進位檔的大小。舉例來說,將 CRC 和 AES 等演算法替換為特殊指令,會產生速度更快且更小的程式碼。
輕鬆排解問題,例如二進位檔多樣性:針對不同的 CPU 進行微調,代表隨著時間產生了更多相同邏輯構件的二進位變體。例如,核心映像檔或預建共用程式庫的多個「變種版本」,分別針對不同的目標進行最佳化。這可能會導致重製問題更複雜,或公開 Fuchsia 對某些二進位檔變化版本中引起的問題,但其他變數則否。
關卡遊戲關卡:除了基準版本外,Fuchsia 也可能會提供專為特定 CPU 設計的 SDK 預建 (系統映像檔、可轉散的共用程式庫)。這樣做可以獲得某些硬體選項的有限權限。合理的假設是,建立可針對某些 CPU 調整的 SDK 變種版本,這會造成未來預期提供更多經過調整的 SDK 發布管道的期望。
簡易:以上所有項目都會在瞭解 Fuchsia、開發 Fuchsia 及維護 Fuchsia 等方面,都增添複雜度。上述優缺點是設定 CPU 指定選項,在可能的情況下引入二進位多樣性,在適用於特定硬體的建構和發布管道上,例如建構和發布管道 (針對特定使用者硬體指定 OTA 管道)。在撰寫本文時,系統或套件提交機制並沒有提供多個二進位檔給不同目標硬體的機制,而是將合適的二進位檔對應至正確的裝置。
提案
您可以前往這項變更查看立即提議的修改內容。詳情請見下文。
新增 arm64 基準硬體目標
arm64 目前的基準定義為以 Cortex-A53 為目標,如下所示:
-mcpu=cortex-a53
從技術上來說,這相當於以精確的 Cortex-A53 功能來表達 -march
,以及調整 Cortex-A53 的程式碼產生器。
-march=<armv8a + Cortex-A53 features>
-mtune=cortex-a53
而基準會表達出由平台實際鍛煉的 ARMv8-A ISA 功能,這類功能會假設為基準,然後微調一般 armv8a CPU。
-march=armv8-a+simd+crc+crypto
-mtune=generic
對 -march
的影響,實際上這是免人工管理,因為移除 Cortex-A53 支援的 -march
功能,但並未在程式碼中執行。
由於一般調整目標會針對 Cortex-A53 等一般順序調整目標 (例如 Cortex-A53),因此對 -mtune
的影響最小或完全沒有效果。
現有 x64 基準硬體目標變更
x64 目前的基準線如下:
-march=x86-64-v2
本文先前已在上述 RFC-0073:將 x86-64 平台要求提高至 x86-64-v2 中。
這會變更為以下標記:
-march=x86-64-v2
-mtune=generic
這並非行為變更,因為如之前所述,如果未指定 -mtune
或 -mcpu
,-mtune
會預設為 generic
。不過,新增 -mtune=generic
會讓這個行為更明確,且與 arm64 基準定義一致。
主面板設定
系統會繼續使用主面板專用 .gni
檔案中指定的 board_configs
主面板引數 (例如在 //boards/
中找到的引數),以主面板專屬設定覆寫基準設定。
具體來說,主機設定 (例如使用 Cortex-A53 的 astro.gni
和 sherlock.gni
) 會繼續鎖定 Cortex-A53,並保留目前的 -mcpu=cortex-a53
設定。
基本上,這項 RFC 會採用以 Cortex-A53 為目標的現有 arm64 設定,並從平台基準擷取該設定,將其從平台基準線擷取到搭載這些 CPU 的 Astro 和 Sherlock 主機板專用設定。然後,此 RFC 以 ARM ISA 詞彙重新定義平台基準,該詞彙一般適用於許多硬體選擇,而非針對單一 ARM CPU。
此外,您可以在日後的 SDK 版本中,針對針對不同架構變化版本 (例如 ARM Cortex-A73 或 Intel AVX 擴充功能) 為目標的最佳化功能新增支援功能。因此,這需要進一步討論,因此不在討論範圍內。
核心設定
board_configs
引數將不再套用至核心映像檔。原因如下:
較新的操作說明或其他必須在程式碼產生時間知道的 CPU 功能,目前對核心沒有益處。
以微架構為基礎的核心程式碼微調作業,並不會因增加二進位檔的多元性和複雜度增加而帶來優勢。
核心可以繼續提供有關支援硬體功能的資訊,例如 zx_system_get_features
系統呼叫。
此外,核心仍可利用一些較新的硬體功能,例如 64kB 記憶體頁面,因為這類頁面不需要產生不同程式碼,只需要在執行階段查詢是否存在這些功能。如果導入這類新功能時需要遊戲板專屬設定,就能輕鬆導入新的引數 kernel_board_configs
來定義相關標記。
回溯相容性
在這個 RFC 中提出的立即變更,不會提高 Fuchsia 的最低硬體需求,因此回溯相容性不受影響。日後如有提高最低需求的變更,可能會受這個 RFC 推展的政策所影響。
安全性考量
Fuchsia 使用或打算使用多項 CPU 功能來提高安全性,或支援使用消毒液 (從而提升安全性)。這些功能通常不受本文討論的編譯器旗標控管,因此不必擔心。
值得注意的是:
- Userspace Top-Byte-Ignore (請參閱 RFC-0143 這在 AArch64 中普遍受到支援)。
- 新操作說明可改善消毒器支援 (例如 ARM MTE),或確保控制流程完整性 (例如指標驗證和分支目標識別或 Intel 控制流程強制執行技術) 位於 NOP 空間,使這些指示具有回溯相容性,因為較舊 CPU 可當做 NOP 執行。因此,就算遵循上述操作說明,您不一定要提高平台或 SDK 版本支援的最低 ISA。
測試
正確性:變更 CPU 指定功能,絕對不會損害正確性。這種做法的驗證方式包括連續提交和提交後的測試。現在的系統已足以確保這一點。
效能:變更 CPU 指定功能通常會對效能產生影響。系統會使用 Fuchsia 的 Perfcompare 系統驗證所有這類變更,就像從「之前」一樣。
二進位檔大小:變更 CPU 指定功能通常會稍微影響二進位檔大小。具體來說, Fuchsia 目前最接近會追蹤天文映像檔的大小,因為這是我們目前擁有最受限的目標。立即變更不會迴歸這個大小。未來會影響特定產品圖片的變更,都可由這些產品定義的擁有者審閱及仔細思考如何取捨。
缺點、替代方案和未知
CPU 指定功能需要在工程和業務方面權衡許多利弊,但有時卻發生衝突。請參閱上述內容。未來有哪些利弊,以及日後的調整機會和考量,都不在這個 RFC 的範圍內。