[Haskell-cafe] rewrite rules to specialize function according to type class?

Roman Leshchinskiy rl at cse.unsw.edu.au
Tue Feb 15 18:28:33 CET 2011

Max Bolingbroke wrote:
> On 15 February 2011 16:45, Roman Leshchinskiy <rl at cse.unsw.edu.au> wrote:
>> Only if foo has an INLINE pragma. Otherwise, GHC uses whatever RHS is
>> available when it wants to inline.
> Ah, I see! Well yes, in that case my workaround is indeed broken in
> the way you describe, and there is no way to repair it because in my
> proposal you wouldn't be able to write an INLINE pragma on the actual
> default method definition.

There is an alternative, actually. When compiling a module with a function
that doesn't have an INLINE pragma, GHC uses its optimised rhs for
inlining in every stage and then records its unfolding for use in other
modules if it is small enough to be inlined. This has some unfortunate
(IMO) implications. Consider the following code:

{-# INLINE [1] f #-}
f = <big>
g = f
h = g

Will <big> be inlined into h? This depends on the module that h is defined
in. If it's in the same module as g, then g will most likely be inlined
into h in phase 2, i.e., before f has been inlined into g. Then, f will be
inlined into both g and h in phase 1. However, after f is inlined into g,
g's rhs becomes too big for inlining. So if h is defined in a different
module, g won't be inlined into it.

We could just as well say that a function's rhs should be recorded forever
as soon as it becomes small enough to be considered for inlining. So GHC
could notice that g is very small in phase 2 and basically add an
INLINABLE pragma to it at that point, regardless of what happens to its
rhs afterwards. This would ensure that inlining isn't affected by
splitting things into modules and would probably also make your proposal
work. But it would also result in a lot more inlining compared to now.


More information about the Haskell-Cafe mailing list