使用LLVM字節代碼庫（而不是原始目標文件）

Question

什麼是對

• 可移植性（調用約定：它真的在LLVM的水平關係時只調用到C或OS庫函數）的影響
• 鏈接時
• 優化

我想編譯LLVM玩具語言，因爲所有已經存在（優化，目標代碼的生成）困難的部分，但我掙扎着一個我想保留的概念，如果它是值得的：庫文件應該是可重新分發的，可用作靜態和共享庫（用於鏈接，在共享的情況下，當鏈接最終應用程序時，會生成一個真正的so或dll） ），便攜式。我相信這會減少部分編譯時間（因爲本地代碼生成和可能的優化只在最終的二進制鏈接時間完成一次）。我設想鏈接器負責調用約定（如果可能的話）以及在需要時轉換爲共享庫。在遠距離擴展中，可能會將LLVM用於而不是鏈接，並使用LLVM JIT直接運行生成的字節碼，在編寫代碼時完全刪除鏈接時間。

這聽起來

1. 可行？
2. 值得嗎？我知道C/C++鏈接時間相對較長，這在經常重建時很成問題。自由鏈接時間優化（cfr /GL和-flto，因爲它本質上將LLVM字節碼鏈接在一起，然後將轉換爲本機二進制）。

這可能是一個模糊的問題，如果我必須澄清一些事情，請詢問。

Answer 1

我在過去做過類似的事情。有一點你應該認識到，LLVM位碼不是「便攜」的，因爲它不完全獨立於機器。位碼文件具有諸如針對處理器特定的指針大小等的知識。

話雖如此，過去我已編譯程序及其支持庫到位代碼並將位代碼文件鏈接在一起，然後生成整個程序的程序集文件。你說得對，調用約定對於內部調用並不重要，但在外部（或外部）調用仍然需要遵循ABI。

您可能可以設計玩具語言，以避免依賴於處理器的位代碼，但您必須非常小心。

我注意到將位碼文件連接在一起花了相當長的時間，特別是在高優化級別。現在可能已經加快了，我在2到3年前就使用了LLVM。

最後一點：根據目標處理器的不同，您可能需要libgcc.a或compiler-rt來處理處理器不能像浮點或64位整數的東西，如果處理器不'沒有執行這些操作的指令。