作者mshockwave (夏克維夫)
看板CompilerDev
標題[分享] LLVM 預設使用新的PassManager
時間Wed Feb 17 12:35:18 2021
好像有一點lag了 但LLVM現在預設使用新的 PassManager了：
https://tinyurl.com/296ekhzz
這改動包括Clang, LLD, 還有 gold (LTO) plugin
新的 PassManager 在(編譯器本身)運行速度還有記憶體消耗上都有顯著的改善
至於編譯出來的程式品質的話...我是沒聽說有變比較快 應該還是差不多
如果單純只是使用clang、這改動基本上沒什麼差，但如果你有寫 LLVM Pass 的話、
新的PassManager很遺憾的不相容舊的Pass。就連 plugin 也不會相容。
opt的關於除錯Pass相關的CLI flags也有些許的不一樣。
個人是蠻樂見這件事成真的啦 因為編譯速度真的是常被忽略的一個課題
可能許多人還以為只有 JIT 才要在意編譯速度，但事實上很多傳統的軟體(例如
Chromium) 規模已經大到編譯時間會太長而拖垮生產力XDDD
其他領域例如遊戲開發也有這個問題。在LLVM mailing list 上就偶爾會聽到
來自 Unity Game Engine 的人點出編譯速度問題，PlayStation的人也反映相同的問題
現在社群裡面在討論的是也要把 code generation pipeline更新為新的 PassManager
因為目前 code generation Pass，也就是那些處理 MachineFunction 的 Pass，還是
用舊的體系。我個人對這個倒是沒什麼特別的感覺，因為如果要改善 codegen 部分的
速度，要優化的應該是 instruction selection 或者甚至 register allocation
的演算法，因為這兩位才是最大的效能瓶頸
以上個人一點淺見<(_ _)>
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 169.234.228.165 (美國)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/CompilerDev/M.1613536521.A.B87.html
1F：推 PsMonkey: GWT 的編譯速度已經被訐譙十幾年了 XD 02/17 15:51
2F：推 Lipraxde: Instruction selection 和 register allocation 確實是 02/19 22:49
3F：→ Lipraxde: 佔蠻多時間，不過在 function 小且數量多的時候花在舊 02/19 22:49
4F：→ Lipraxde: 的 pass manager 上的時間我是覺得蠻有感的 02/19 22:49
5F：→ Lipraxde: 不過我不知道換成用新的可以快多少就是了 02/19 22:50
6F：推 ChampYen: 感謝新知 02/20 01:00
7F：推 eopXD: 推推！！ 08/22 16:05