Looking at the code in Specialise, there are only two differences in the way that UnspecArg and UnspecType are treated differently:

* In specHeader, small differences

* In ppr_call_key_ty, when generating the name of the RULE

So we could collapse them into SpecArg, and fix the small differences some other way.

But 'd have thought it was easier just to get the right SpecArg/SpecType for the padding for DFuns. That's not hard. Something like

```

do { let all_call_args | is_dfun = call_args ++ map mk_extra_dfun_arg (dropList call_args rhs_bndrs)
| otherwise = call_args
-- See Note [Specialising DFuns]

mk_extra_dfun_arg bndr | isTyVar bndrs = UnspecType

| otherwise = UnspecArg

```

This is really a GHC bug already, albeit one that is hard to provoke. Would you like to open a ticket and add the fix?

Simon

On Sat, 30 Apr 2022 at 10:27, ÉRDI Gergő <gergo@erdi.hu> wrote:

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
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs