Skip to content

Try eta-expanding PAPs

Simon Peyton Jones requested to merge wip/T22886 into master

This is an experimental patch, motivated by #22886, which tries eta-expanding PAPs.

Let's see what effect that has.

Here is the existing Note in GHC.Core.Opt.Simplify.Utils which argues for not eta-expanding PAPs

Note [Do not eta-expand PAPs]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We used to have old_arity = manifestArity rhs, which meant that we
would eta-expand even PAPs.  But this gives no particular advantage,
and can lead to a massive blow-up in code size, exhibited by #9020.
Suppose we have a PAP
    foo :: IO ()
    foo = returnIO ()
Then we can eta-expand to
    foo = (\eta. (returnIO () |> sym g) eta) |> g
where
    g :: IO () ~ State# RealWorld -> (# State# RealWorld, () #)

But there is really no point in doing this, and it generates masses of
coercions and whatnot that eventually disappear again. For T9020, GHC
allocated 6.6G before, and 0.8G afterwards; and residency dropped from
1.8G to 45M.

Moreover, if we eta expand
        f = g d  ==>  f = \x. g d x
that might in turn make g inline (if it has an inline pragma), which
we might not want.  After all, INLINE pragmas say "inline only when
saturated" so we don't want to be too gung-ho about saturating!

But note that this won't eta-expand, say
  f = \g -> map g
Does it matter not eta-expanding such functions?  I'm not sure.  Perhaps
strictness analysis will have less to bite on?

Merge request reports