我總覺得開源是一種信仰。在一個想像的共同體下大家用自己的雙手把這個共同體不斷變得更好。編譯器這麼博大精深，除了會碰到的東西之外，這場會議讓我有機會看到大家正在 LLVM 這個巨大的 mono-repo 底下正在做什麼樣的 project 和努力，某些時刻真的是倍感溫馨。
Thanks
真的非常高興能透過公司，出差參加在 San Jose 舉辦的 LLVM Developers’ Meeting。因為疫情的關係已經三年沒有舉辦實體的 LLVM Developers’ Meeting 了，能參加疫情後復出的第一次真是幸運。
在這裡首先要感謝 SiFive 能夠贊助我這次的旅行（機票、住宿、伙食、交通、報名費全包），感謝 compiler team（Alice、一休、還有組內的大家）在有限的名額下讓我有這機會可以出去見見世面，也要感謝跟我同行的同事 Kito。另外還有感謝近期 Meta 裁員中活下來的灣區地頭蛇奇宥請我吃晚餐還有打高爾夫，感謝 Mircea 還有 Yundi 帶我去 Google 蹭免費的伙食。
Talks / Panels / Round Tables
對於每個技術 talk 的實際內容，我想之後都會放在網路上給大家觀看，在這邊簡短 dump 一下我在這次會議中參與的 talk / panel / round table。如果有人看到這篇文想要線下跟我討論的話絕對是非常歡迎。
這次的議程基本上是雙軌制，從 09:00 到 17:30 每一個時刻有兩個演講廳正在同時進行，並外掛一個有若干圓桌的空間給 round table 使用。（可以在這裡看到議程）
Keynote: Path towards unifying LLVM and MLIR
對所有參加者引入 Strate 跟 Dialect 的概念，而 MLIR 確實有他的長處，也列出一張很大的表格來展示目前在功能性上兩者的差異（e.g. MLIR 支援 Region，BasicBlock input arguments）。
LLVM 本身其實已經分化出了 “Dialect 般的概念”，也就是那些除了 primitive LLVM IR 以外由的 IR，只是他們統一的被概括在 LLVM IR 底下。
在整合 MLIR 和 LLVM 這兩個 substrate 的路上，一個可能的做法是讓 pass 可以是在兩個 substrate 間是通用的。藉由整合介面、member type 來達到。這包括非常冗長的重新命名過程，不過現在在談的十年的願景嘛～
Heterogeneous debug metadata in LLVM
展示如何解決 GPU 上對異質記憶體 memory allocation 的問題。在 heterogenous 的環境底下一個變數可能有多個記憶體位置來儲存。在 metadata 中附加 LocalVariable、Lifetime、Object 的資訊來與 register allocation 掛鉤。
工作的最剛開始 Skymizer 只接觸到很簡單的異質架構，現在作為 CPU compiler engineer 還沒有進入 GPU 的世界。期待以後可以繼續增長見聞。
Interactive crashlogs in LLDB
從 Apple 來的人做了超級超級潮的投影片，用動畫把 terminal 上的 error dump 還有實際 script 的 code trace 做得很生動。
Panel: High-level IR-s for a C / C++ optimizing compiler
我覺得這場 panel 很有娛樂性 XD 基本上是 Johannes 大戰其他 MLIR 擁護者。因為這場 Chris Lattner 也在其中，旁聽人數很高。
私底下的聊天中，其實 Johannes 也知道 MLIR 的好處，MLIR 的架構使得創立額外的抽象層變得容易。他懷疑的是作為一個 generic compiler 為什麼大家這麼衝動的想要把現在 LLVM 的東西搬到 MLIR 上。如果 MLIR 是一個很明顯的優勝者，那麼大家一定會毫不猶豫的這麼做，但是在沒有其他人與 MLIR 競爭的情況下，很容易變成一種 Infra 獨大的情況。他不知道自己到底樂不樂見這樣的事發生。
What does it take to run LLVM Build-bots
超酷的 talk，從來不知道 LLVM 的 buildbot 背後是誰在支持，原來是 Arm 付錢給 Linaro 在做這個繁重的工作。
一個有挑戰性的目標是讓 LLVM main branch 永遠是 all pass 的。這需要把每個要 merge 進去的 commit 丟進一個 queue 中確認 full build 沒問題後再進去。他需要非常精準的計算出需要多少機器/資源來達成這樣的目標。
有趣的冷知識：LLVM mono-repo 平均來說每小時會有 4 個 commit 發生
Round table: Loop optimization
從上一場 round table 跳到這個，覺得是 dynamic pass manager 討論的延伸。現在的 loop optimization 之間太多 dependency，而且 LLVM 中也缺乏一個讓我們探索 phase ordering 問題的 infra，會繼續追蹤 Alina 對 dynamic pass manager 的後續。
雖然這次的議程比較少 middle-end / back-end 相關的 talk，但是能夠看到剛好讓我有機會踢到自己舒適圈以外的東西，覺得這也是很寶貴的經驗。
值得一提的記憶碎片
見到今年 GSoC 的導師 Mircea 還有 Johannes，還有在 MLGO 下做另一個 GSoC project 的 Aiden。能跟他們實際見到然後聊天很開心。後來還跟 Mircea 去 Movement Santa Clara 一起攀岩，有天中午他跟 Yundi 帶我去 Google Sunnyvale 吃了裡面的午餐，覺得他真的很照顧人。
遇到一個在 Nintendo 工作的幽默大叔，他提到他們招人的方式都是從 contractor 開始做起，認為這樣可以最大的避免 false positive 發生。仔細想想也確實，但這做法適用在 Senior 的招聘上嗎！？
食物實在是有點普通，覺得有點愧對 $900 的報名費。個人的推理原因或許是：
- 會場容納人數有限，當你預期辦一場會議想要賺到多少錢時，當總人數變少只能把報名費拉高了
- 之前 virtual 會議都沒有收報名費，基金會需要從睽違已久的復辦中注入資金持續正常營運
- Hayes Mansion 其實是個很精緻的地方（可說實在不是一個辦 400+ 人會議的好地方，會議當第一天還下雨導致大家只能在室內聊天），報名費還有會場的接待人員想當然也不會太便宜。
晚上餐會跟在 Argonne 工作的 Michael 同桌吃飯。跟他聊到我想重寫 LSR，結果被他嚴正的用 GVN 的悲慘故事勸退。從前有個在 Google 工作的人就在社群上寫了個新的 GVN 取代舊的。但是新的 GVN 替換後踩出了各種 bug 使得原作者要不斷 patch 來修復。但是後來原作者因為在 G 社被升職了就沒時間繼續維護 GVN，到頭來大家只能回頭用舊的⋯⋯這故事確實淒慘，但我對 LSR 的執念還是好深，現在 LLVM 上的實作確實欠佳⋯⋯但是一動就會牽動到所有 target 的行為，以企業的角度來說沒什麼道理在這邊投入資源。
後來還跟他聊到最近請他 review 的 patch 到底有什麼問題。當場用手機打開 Phabricator 叫她說個明白，一比之下他發現他自己眼殘，當場就把 patch approve 了。吃晚餐賺 patch！
見到最近加入 Rivos 在 RISC-V 很活躍的 Philip，跟他聊起了我最近在社群上推動 RVV intrinsics 的現況。有趣的是，他說了類似這樣的句子，”I don’t care what GCC does, but I want things don’t get messy in LLVM.”。而我在跟 Kito 的討論中 Kito 則是說，「反正不管 LLVM 怎麼做，GCC 就是會去實現 intrinsics spec. v1.0」。把兩個源自不同社群的人說的話放在一起對比真是有趣。
在和 Craig, Philip （註：Craig 是同組的美國同事，目前 LLVM commit 數總排名第二的超強後端戰力）走到晚餐會場的時候，他們開始跟我炫耀他們衣櫃裡有多少 LLVM 相關的 t-shirt。他們兩個都是在社群裡面貢獻非常卓越的人，他們對這個社群的熱愛還有自豪讓我覺得很溫馨。
小結
真的很開心可以參加這次的大型網友見面會。除了上述片段之外還有很多 small talk 實在是族繁不及備載。
期待以後有機會去歐洲場時跟來自歐洲的開發者見面！
eopXD 