PUBLIC
PUBLIC
Hi Simon, Matt & others,
It took me until now to be able to try out GHC HEAD, mostly because I had to adapt to all the GHC.Unit.* refactorings. However, now I am on
a466b02492f73a43c6cb9ce69491fc85234b9559 which includes the commit Simon pointed out. My original plan was to expose
the first half of specProgram, i.e. the part that calls `go binds`. I did that because I want to apply specialisation on collected whole-program Core, not just whatever would be in scope for a Core-to-Core plugin pass, so I am not writing a CoreM and I don’t
even have a ModGuts at hand.
However, I found out from Matt’s email on this thread that this is not going to be enough and eventually I’ll need to figure out how I intend to apply the rewrite rules that
come out of this. So for now, I am just turning on specialization in the normal pipeline by setting Opt_Specialise, Opt_SpecialiseAggressively, and Opt_CrossModuleSpecialise. And I’m still not seeing $dm>> being specialized.
Is this because I define each of “class Monad”, “data IO a”, “instance Monad IO”, and “main”, in four distinct modules? In other words, is this something I will not be able to
try out until I figure out how to make a fake ModGuts and run a CoreM from outside the normal compilation pipeline, feeding it the whole-program collected CoreBinds? But if so, why is it that when I feed my whole program to just specBinds (which I can try
easily since it has no ModGuts/CoreM dependency other than a uniq supply and the CoreProgram), I get back an empty UsageDetails?
Thanks,
Gergo
For reference, the relevant definitions dumped from GHC with specialization (supposedly) turned on:
main = $fMonadIO_$c>> @() @() sat_sJg xmain
$fMonadIO_$c>> :: forall a b. IO a -> IO b -> IO b
$fMonadIO_$c>> = \ (@a_aF9) (@b_aFa) -> $dm>> @IO $fMonadIO @a_aF9 @b_aFa;
$dm>> :: forall (m :: Type -> Type) a b. Monad m => m a -> m b -> m b
$dm>>
= \ (@(m_ani :: Type -> Type))
($dMonad_sIi [Occ=Once1] :: Monad m_ani)
(@a_ar4)
(@b_ar5)
(ma_sIj [Occ=Once1] :: m_ani a_ar4)
(mb_sIk [Occ=OnceL1] :: m_ani b_ar5) ->
let {
sat_sIm [Occ=Once1] :: a_ar4 -> m_ani b_ar5
[LclId]
sat_sIm = \ _ [Occ=Dead] -> mb_sIk } in
>>= @m_ani $dMonad_sIi @a_ar4 @b_ar5 ma_sIj sat_sIm
From: Erdi, Gergo
Sent: Thursday, October 7, 2021 9:30 AM
To: Simon Peyton Jones <simonpj@microsoft.com>
Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com>; GHC <ghc-devs@haskell.org>
Subject: RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*)
PUBLIC
Indeed, I am using 9.0.1. I’ll try upgrading. Thanks!
From: Simon Peyton Jones <simonpj@microsoft.com>
Sent: Wednesday, October 6, 2021 6:12 PM
To: Erdi, Gergo <Gergo.Erdi@sc.com>
Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com>; GHC <ghc-devs@haskell.org>
Subject: [External] RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*)
Grego,
Yes I think that should auto-specialise.
Which version of GHC are you using? Do you have this patch?
commit ef0135934fe32da5b5bb730dbce74262e23e72e8
Author: Simon Peyton Jones
simonpj@microsoft.com
Date: Thu Apr 8 22:42:31 2021 +0100
Make the specialiser handle polymorphic specialisation
Here’s why I ask. The call
$fMonadIO_$c>> = \ (@a) (@b) -> $dm>> @IO $fMonadIO @a @b
indeed applies $dm>> to $fMonadIO, but it also applies it to a and b. In the version of GHC you have, maybe that stops the call from floating up to the definition site, and being used to specialise it.
Can you make a repro case without your plugin?
Simon
PS: I am leaving Microsoft at the end of November 2021, at which point
simonpj@microsoft.com will cease to work. Use
simon.peytonjones@gmail.com instead. (For now, it just forwards to
simonpj@microsoft.com.)