[八卦] LLILC項目貌似掛了…

關於LLILC是什麼，請跳傳送門：如何看待微軟LLILC，一個新的基於LLVM的CoreCLR JIT/CoreRT AOT編譯器？

Andy Ayers大大會不會抓狂了，Phoenix和LLILC都掛了的話…

============================================

LLILC項目的開發過程上可能也有些隱患。

其中很有趣很subtle的一點是：他們在項目初期決定先實現對MSIL的大範圍的支持，為此抄了些捷徑：

• 生成LLVM IR後，幾乎不打開LLVM的優化pass，直接去生成目標代碼
• 使用CoreCLR的GC的後備漠視——保守式GC（conservative GC），這樣就可以讓LLILC不處理棧上的託管指針，而是讓CoreCLR自己去保守式掃描棧上的值去猜哪些是託管指針。

這倆捷徑的好處是項目初期可以快速推進進度，把大部分MSIL指令都支持上，讓LLILC可以編譯一些小程序來測試。

但壞處在後期會慢慢浮現出來：一個編譯器前端在生成LLVM IR後，如果不打開LLVM的優化pass來編譯，其實無法確定到底生成的IR對不對——有沒有正確實現想要表達的語義。如果有些代碼生成模式已經大規模寫進去了，然後才發現不對，那改起來就會極其痛苦。畢竟最終LLILC還是想要打開LLVM的優化的，不然要它來幹嘛，所以這不得不面對的問題，還是早點面對了比較好。

而藉由CoreCLR的conservative GC支持的初步運行也可能掩蓋了一些其實難以解決的問題，等後面真的要嘗試解決的時候才發現困難的話多頭疼。

說來，LLILC一開始就決定放棄CoreCLR的JIT所支持的「fully interruptible code」了。這種東西用LLVM實現確實非常彆扭，放棄就放棄吧。

============================================

不知道他們是不是遇到了什麼解決起來很麻煩（我不想說「無法解決」）的技術問題，導致這個項目被放棄/擱置/降低優先順序了。C# / CLR需要支持的功能確實比Java要複雜許多，因此LLILC也遇到了許多我們在我們的基於LLVM的JVM JIT編譯器里不會遇到的問題。

同事提到，跟LLILC組的人討論的時候，他們提出過許多問題。

其中一個是：C#有value type，在CLR / CoreCLR的實現中value type既可能被分配在棧幀里，也可能被box後分配在託管堆里；而且C#還支持pass-by-reference的參數傳遞模式，一個類型為value type的reference到底是引用著一個棧上還是堆上的value type實例，從被調用方法的一側是無從知道的。然而如果用LLVM的address space來實現對普通內存（用默認address space）和託管堆內存（用某個自定義address space）的區分，LLVM就要求要把指針聲明為對應的address space，這樣一個指針就不允許既可能指向棧上對象又可能指向堆上對象，於是處理起來就有點麻煩。

另外，C#的value type里可以包含託管指針欄位。如果一個含有託管指針欄位的value type值被分配在棧上，而GC又要求對棧上的託管指針做準確式掃描（precise GC / type-exact GC），那麼當然這些棧上的託管指針要能被正確處理。然而Azul給LLVM加入的gc.statepoint並不能直接處理這種情況——gc.statepoint所能指定的root set都是LLVM IR意義上的SSA value，而不包括實際在內存棧幀里的值；即便給gc.statepoint添加對棧幀內存的支持，在LLVM IR里想要精確控制整個棧幀在內存里的布局是非常困難甚至可能做不到的——是，每一個alloca內部的布局是可以精確控制的，但如果我們想精確控制某個slot在棧幀里的實際偏移量，做不到。而C#的value type是一個需要精確控制內存布局的聚合類型（aggregate type），我們不能說把裡面的欄位給打散了分別處理然後再聚合回來，而總是得保證整個value type的值打包在一起處理。<- 讓我找找看LLILC的issues或者wiki之類的地方有沒有人討論過這個問題然後再來補充。

推薦閱讀：