<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Looking at the code in Specialise, there are only two differences in the way that UnspecArg and UnspecType are treated differently:</div><div class="gmail_default" style="font-family:tahoma,sans-serif">* In specHeader, small differences</div><div class="gmail_default" style="font-family:tahoma,sans-serif">* In ppr_call_key_ty, when generating the name of the RULE</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">So we could collapse them into SpecArg, and fix the small differences some other way.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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</div><div class="gmail_default" style="font-family:tahoma,sans-serif">```</div><div class="gmail_default" style="font-family:tahoma,sans-serif"> do { let all_call_args | is_dfun = call_args ++ map mk_extra_dfun_arg (dropList call_args rhs_bndrs)<br> | otherwise = call_args<br> -- See Note [Specialising DFuns]</div><div class="gmail_default" style="font-family:tahoma,sans-serif"> mk_extra_dfun_arg bndr | isTyVar bndrs = UnspecType</div><div class="gmail_default" style="font-family:tahoma,sans-serif"> | otherwise = UnspecArg<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"> ```</div><div class="gmail_default" style="font-family:tahoma,sans-serif">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?</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 30 Apr 2022 at 10:27, ÉRDI Gergő <<a href="mailto:gergo@erdi.hu">gergo@erdi.hu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
In GHC.Core.Opt.Specialise.specCalls, when specialising a DFun call, GHC <br>
extends the call_args with dummy UnspecArg elements, to make it trivially <br>
fully saturated. There's a Note describing this behaviour:<br>
<br>
"""<br>
Note [Specialising DFuns]<br>
~~~~~~~~~~~~~~~~~~~~~~~~~<br>
DFuns have a special sort of unfolding (DFunUnfolding), and these are<br>
hard to specialise a DFunUnfolding to give another DFunUnfolding<br>
unless the DFun is fully applied (#18120). So, in the case of DFunIds<br>
we simply extend the CallKey with trailing UnspecArgs, so we'll<br>
generate a rule that completely saturates the DFun.<br>
<br>
There is an ASSERT that checks this, in the DFunUnfolding case of<br>
GHC.Core.Unfold.specUnfolding.<br>
"""<br>
<br>
(note that the reference in the second paragraph is stale; it should point <br>
to GHC.Core.Unfold.Make.specUnfolding)<br>
<br>
So my question is, why UnspecArgs instead of UnspecTypes? Unless I'm <br>
missing something, a DFun can't have any term parameters, only type and <br>
dictionary ones. Changing the padding from UnspecArg to UnspecType doesn't <br>
break validate, which suggests that it is hard to even exercise this code <br>
path.<br>
<br>
I'm bringing this up because on the GHC fork that I'm working on, I have <br>
the specializer do more than vanilla GHC: on my fork, specialization of<br>
higher-kinded type variables is just as useful as specializing <br>
dictionaries. With that change, I can get GHC panics when padding DFun <br>
calls with UnspecArgs, but not when padding with UnspecTypes. Yes, this is <br>
a very weak argument for this change; what I'm looking for here is a <br>
discussion on what the padding should be, in vanilla GHC, from first <br>
principles.<br>
<br>
Thanks,<br>
Gergo<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>