是否有任何理由不使用INLINABLE编译指示功能？ [英] Is there any reason not to use the INLINABLE pragma for a function?

问题描述

文档指出：

函数f上的{ - ＃INLINABLE f＃ - } pragma具有以下行为：

• 尽管INLINE说请将我内联，但INLINABLE表示随意与我联系;请谨慎使用。换句话说，选择留给GHC，它使用与无杂注函数相同的规则。与INLINE不同，该决定是在呼叫站点进行的，因此将受到内联阈值，优化级别等的影响。

与INLINE一样，INLINABLE编译指示保留原始RHS的内联目的副本，并将其保存在接口文件中，而不管RHS的大小如何。


• 使用INLINABLE的一种方法是与特殊函数inline结合使用（第7.18节特殊内置函数）。内联调用f非常难以内联f。为了确保f可以内联，最好将f的定义标记为INLINABLE，以便GHC保证揭示展开，而不管其大小如何。此外，通过将f注释为INLINABLE，您可以确保f的原始RHS被内联，而不是GHC的优化器生成的任何随机优化版本。 INLINABLE pragma也适用于SPECIALIZE：如果将函数f标记为INLINABLE，那么随后可以在另一个模块中使用SPECIALIZE（请参见第7.16.8节 SPECIALIZE pragma）。 与INLINE不同，在递归函数中使用INLINABLE pragma是可以的。主要原因是为了以后可以使用SPECIALIZE b $ b / b> b $ b

缺点是什么它是什么？

它是否使界面文件更大，更大？它是否会使编译速度变慢？

是否有任何理由不应该在我编写的每个导出函数上放置INLINABLE编译指示？有没有什么原因GHC不会在我写的每个导出函数上放置一个INLINABLE编译指示？

使用 INLINABLE并且根本不使用pragma：

• 如果没有INLINABLE，接口文件中的定义是代码在优化之后，而使用INLINABLE时，它是您编写的代码（或多或少）。特别是，如果没有INLINABLE，GHC可能会将其他函数内联到函数的定义中。
  

• 如果没有INLINABLE，GHC将会从接口文件中删除定义，如果它太大。如果其他功能内嵌到右侧，这可以很容易地将其推到极限。

INLINABLE还会打开一些智能机器，专用于使用它们的重载函数，并与其他模块共享专用版本，这些模块可以传输导入创建专用版本的模块。

The documentation states:

An {-# INLINABLE f #-} pragma on a function f has the following behaviour:

• While INLINE says "please inline me", the INLINABLE says "feel free to inline me; use your discretion". In other words the choice is left to GHC, which uses the same rules as for pragma-free functions. Unlike INLINE, that decision is made at the call site, and will therefore be affected by the inlining threshold, optimisation level etc.

• Like INLINE, the INLINABLE pragma retains a copy of the original RHS for inlining purposes, and persists it in the interface file, regardless of the size of the RHS.

• One way to use INLINABLE is in conjunction with the special function inline (Section 7.18, "Special built-in functions"). The call inline f tries very hard to inline f. To make sure that f can be inlined, it is a good idea to mark the definition of f as INLINABLE, so that GHC guarantees to expose an unfolding regardless of how big it is. Moreover, by annotating f as INLINABLE, you ensure that f's original RHS is inlined, rather than whatever random optimised version of f GHC's optimiser has produced.

• The INLINABLE pragma also works with SPECIALISE: if you mark function f as INLINABLE, then you can subsequently SPECIALISE in another module (see Section 7.16.8, "SPECIALIZE pragma").

• Unlike INLINE, it is OK to use an INLINABLE pragma on a recursive function. The principal reason do to so to allow later use of SPECIALISE

What's the disadvantage of it?

Does it make interface files much, much bigger? Does it make compilation much slower?

Is there any reason I shouldn't put an INLINABLE pragma on every exported function I write? Is there any reason GHC doesn't put an INLINABLE pragma on every exported function I write?

解决方案

There are three differences between using INLINABLE and not using a pragma at all:

• Without INLINABLE, the definition that goes in the interface file is the code after optimisation, whereas with INLINABLE, it is the code you wrote (more or less). In particular, without INLINABLE, GHC might inline other functions into the function's definition.

• Without INLINABLE, GHC will omit the definition from the interface file if it is too big. If some other function got inlined into the right-hand-side, this could easily push it over the limit.

• INLINABLE also turns on some clever machinery that automatically specialises overloaded functions where they are used, and shares the specialised versions with other modules that transitively import the module in which the specialised version was created.

这篇关于是否有任何理由不使用INLINABLE编译指示功能？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！