是否有任何理由不使用INLINABLE pragma作爲函數？

Question

的documentation狀態：

一個吱 - ＃可以內聯F＃ - }在函數f編譯有以下行爲：

• 雖然INLINE說： 「請行內我」 時，可以內聯說： 「隨時聯繫我，使用您的判斷力」。換句話說，選擇留給GHC，它使用與無雜注函數相同的規則。與INLINE不同，該決定是在呼叫站點進行的，因此將受到內聯閾值，優化級別等的影響。

• 與INLINE一樣，INLINABLE編譯指示保留用於內聯目的的原始RHS的副本，它在接口文件中，不管RHS的大小如何。

• 使用INLINABLE的一種方法是與內聯特殊功能（第7.18節「特殊內置功能」）結合使用。內聯調用f非常難以內聯f。爲了確保f可以內聯，最好將f的定義標記爲INLINABLE，以便GHC保證揭示展開，而不管其大小如何。此外，通過將f註釋爲INLINABLE，您可以確保f的原始RHS被內聯，而不是GHC的優化器生成的任何隨機優化版本。如果將函數f標記爲INLINABLE，那麼隨後可以在另一個模塊中進行SPECIALIZE（參見第7.16.8節「SPECIALIZE編譯指示」）。

• 與INLINE不同，可以在遞歸函數上使用INLINABLE雜注。最主要的原因做這樣允許以後使用專門

什麼是它的缺點嗎？

它使接口文件更大，更大嗎？它是否會使編譯速度變慢？

是否有任何理由我不應該在我寫的每個導出函數上放置一個INLINABLE編譯指示？是否有任何理由GHC不會在我寫的每個導出函數上放置一個INLINABLE編譯指示？

Answer 1

有使用可以內聯，而不是使用編譯所有之間的三點區別：

• 沒有可以內聯，那雲在接口文件中的定義是後優化代碼，而與可以內聯，它是你寫的代碼（或多或少）。特別是，如果沒有INLINABLE，GHC可能會將其他函數內聯到函數的定義中。

• 如果沒有INLINABLE，GHC將會從接口文件中省略定義，如果它太大。如果其他功能插入右側，這可能會輕易超過極限。

• INLINABLE還打開了一些巧妙的機制，它們在使用它們時會自動專用重載函數，並與其他模塊共享專用版本，這些模塊可以通過傳輸方式導入創建專用版本的模塊。