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

###### tags: `COSCUP2021` `Skilled` `en` `COSCUP2021` `System Software` `TR309`

{%hackmd kra72OaxRTiBzdV8Y4GMKA %}

:::info
Slido: https://app.sli.do/event/02rn7irj
:::

> 請從這裡開始

講者背景：
- LLVM M68k 後端作者與維護者
- [LLVM Techniques, Tips, and Best Practices Clang and Middle-End Libraries](https://www.amazon.com/gp/product/1838824952) 一書作者

## 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 讓他"熟成"。