LLVM Project: The Good, the Bad, and the Ugly - Min-Yih Hsu

tags: COSCUP2021 Skilled en COSCUP2021 System Software TR309

請從這裡開始

講者背景：

• LLVM M68k 後端作者與維護者
• LLVM Techniques, Tips, and Best Practices Clang and Middle-End Libraries 一書作者

LLVM – The Good Part

Design

Pre-LLVM era：

• 直接複製使用 GCC 相關部分的原始碼：很困難
• 使用 GCC command line interface：不穩定

LLVM 除了大家常聽到的 pass manager 之外，LLVM 以及 clang 前端本身是一般的函式庫，有模組化方便使用者使用任何一部分 – 前端、中間最佳化、後端等等 – 的功能。

LLVM's Improvement of Build-time Performance

隨著各個軟體規模擴大，專案建置需要的時間也開始影響到開發者。

1. 在 code generation 的時候， instruction selection 傳統輸入為 machine-independent 、線性的 IR 表示法，經過 instruction selection 演算法轉成 DAG，最後再轉成線性的 machine-level IR。這些不同 IR 變換消耗非常多的時間。

   LLVM 引進了新的 MLIR 解決後端這部分的問題。

2. Linker 因為需要將所有 object file 鏈結成單一輸出檔，難以將不同工作分配給不同 thread 平行化。同時，近來 linker 也需負責 LTO，為 whole-program optimiztaion，更加難以平行。

   LLVM 的改進: ThinLTO，分開不同的地方平行最佳化，並且在不同的 process 之間以 IPC 交換 function summary 高通。

LLVM community

• 組織：沒有集中的組織作技術決策，整個社群是很扁平的架構。Code owner 只有義務在沒有人 review 程式碼的時候負責處理。

• 貢獻流程：專案只有單一的 main branch。PR 作者直接 與 reviewer 溝通後 commit 到 Tip of Tree (ToT)。

  • 優點：流程簡化
  • 缺點：隨著規模擴大，新的貢獻者難以找到人 review (很多 reviewer 全職在 LLVM -> 很忙 -> 沒時間 review)
  • 嘗試解法：Herald 以及 weekly update 中留意

LLVM – The Ugly

• 缺乏 API 穩定性與向後相容性，並沒有相關的 policy。
  • 函式介面改變 (不同的 name mangling 方式)
  • 有 type-layout 改變(e.g. struct 定義增加新的 field)

LLVM API stability for plugins

LLVM 插件不保證 stability

Q & A

想請問講者對 MLIR的看法？

MLIR 是個框架，讓人更容易的創造新的 domain-specific IR。因此講者很喜歡。

為什麼想維護 LLVM 的 M68K backend?

請問想入門 LLVM 有建議從哪個地方下手嗎？

買講者的書

• 先試著用 LLVM commandline library 在 hello world
• 先從感興趣的部份開始

剛學 SSA form 的話，建議自己寫個 toy，還是研究 LLVM 實作?

如果只是"看"SSA form是怎麼樣的話 用 LLVM/clang dump IR 就好了。如果是想要研究非SSA form轉SSA演算法的話，自己寫應該是不錯的idea

加速 LLVM 編譯速度，是為了加速特定應用 e.g. Rust compiler 嗎？

我會覺得第一當然就是大型專案編譯速度真的很慘，這邊提到的 Rust compiler 也是一個原因之一 (Rust 產生出來的 LLVM IR量以及複雜度遠高於 clang 產出的 LLVM IR)。另外一個有趣的例子是 game developer：PlayStation (他們也是用 clang/LLVM) compiler team近幾年來一直在改進編譯速度的原因就在於 game development 很在意「改動code -> 顯示到畫面」的時間 (他們稱為"turnaround time")，更別提遊戲的複雜度往往比一般軟體高。

abi api的問題是否是在 LLVM版本升級會產生

並沒有一定但是很常發生XDDD。我記得 LLVM 有用一個變數來防止你用 ABI incompatible的 plugin: 只要你用那種 plugin 他在載入 plugin 的時候會跳出一個 dlopen (或是 ld.so 的，我忘記了) error。

請問 LLVM 有計畫仿造其他的開源專案，建立整個社群的權力架構（Review, develop direction）嗎？

我不太清楚這邊講的權力架構是什麼，但就我知道的目前沒這計劃。我知道有一個相關的東西是 LLVM incubator，基本上他的概念跟 Apache incubator 很像：如果你想要在 LLVM project 裡面做某個很大的改動 – 通常是加入某個新的子計劃像是一個 language frontend – 那我們可以先把他丟到 LLVM incubator 讓他"熟成"。