Extending call_args when specialising DFuns

[Simon Peyton Jones]

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 at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220502/8733cd6c/attachment.html>