Hi,
In GHC.Core.Opt.Specialise.specCalls, when specialising a DFun call, GHC
extends the call_args with dummy UnspecArg elements, to make it trivially
fully saturated. There's a Note describing this behaviour:
"""
Note [Specialising DFuns]
~~~~~~~~~~~~~~~~~~~~~~~~~
DFuns have a special sort of unfolding (DFunUnfolding), and these are
hard to specialise a DFunUnfolding to give another DFunUnfolding
unless the DFun is fully applied (#18120). So, in the case of DFunIds
we simply extend the CallKey with trailing UnspecArgs, so we'll
generate a rule that completely saturates the DFun.
There is an ASSERT that checks this, in the DFunUnfolding case of
GHC.Core.Unfold.specUnfolding.
"""
(note that the reference in the second paragraph is stale; it should point
to GHC.Core.Unfold.Make.specUnfolding)
So my question is, why UnspecArgs instead of UnspecTypes? Unless I'm
missing something, a DFun can't have any term parameters, only type and
dictionary ones. Changing the padding from UnspecArg to UnspecType doesn't
break validate, which suggests that it is hard to even exercise this code
path.
I'm bringing this up because on the GHC fork that I'm working on, I have
the specializer do more than vanilla GHC: on my fork, specialization of
higher-kinded type variables is just as useful as specializing
dictionaries. With that change, I can get GHC panics when padding DFun
calls with UnspecArgs, but not when padding with UnspecTypes. Yes, this is
a very weak argument for this change; what I'm looking for here is a
discussion on what the padding should be, in vanilla GHC, from first
principles.
Thanks,
Gergo
