[Git][ghc/ghc][wip/t22549] Transfer DFunId-ness onto specialised bindings

[Matthew Pickering (@mpickering)]

Matthew Pickering pushed to branch wip/t22549 at Glasgow Haskell Compiler / GHC


Commits:
7ecb2983 by GHC GitLab CI at 2023-04-14T09:58:15+01:00
Transfer DFunId-ness onto specialised bindings

Whether a binding is a DFunId or not has consequences for the `-fdicts-strict`
flag, essentially if we are doing demand analysis for a DFunId then `-fdicts-strict` does
not apply because the constraint solver can create recursive groups of dictionaries.

In #22549 this was fixed for the "normal" case, see Note [Do not strictify the argument dictionaries of a dfun]. However the loop still existed if the DFunId was being specialised.

The problem was that the specialiser would specialise a DFunId and turn it into a
VanillaId and so the demand analyser didn't know to apply special treatment to the binding
anymore and the whole recursive group was optimised to bottom.

The solution is to transfer over the DFunId-ness of the binding in the specialiser so
that the demand analysers knows not to apply the `-fstrict-dicts`

Fixes #22549

- - - - -


1 changed file:

- compiler/GHC/Core/Opt/Specialise.hs


Changes:

=====================================
compiler/GHC/Core/Opt/Specialise.hs
=====================================
@@ -48,11 +48,12 @@ import GHC.Types.Unique.DFM
 import GHC.Types.Name
 import GHC.Types.Tickish
 import GHC.Types.Id.Make  ( voidArgId, voidPrimId )
-import GHC.Types.Var      ( PiTyBinder(..), isLocalVar, isInvisibleFunArg )
+import GHC.Types.Var      ( PiTyBinder(..), isLocalVar, isInvisibleFunArg, setIdDetails )
 import GHC.Types.Var.Set
 import GHC.Types.Var.Env
 import GHC.Types.Id
 import GHC.Types.Error
+import GHC.Types.Id.Info
 
 import GHC.Utils.Error ( mkMCDiagnostic )
 import GHC.Utils.Monad    ( foldlM )
@@ -3444,11 +3445,22 @@ newSpecIdSM :: Id -> Type -> Maybe JoinArity -> SpecM Id
 newSpecIdSM old_id new_ty join_arity_maybe
   = do  { uniq <- getUniqueM
         ; let name    = idName old_id
+              details = idDetails old_id
               new_occ = mkSpecOcc (nameOccName name)
               new_id  = mkUserLocal new_occ uniq ManyTy new_ty (getSrcSpan name)
                           `asJoinId_maybe` join_arity_maybe
+                          -- See Note [Transfer DFunId-ness during specialisation]
+                          `transferDFun` details
         ; return new_id }
 
+
+infixl 1 `transferDFun`
+transferDFun :: Id -> IdDetails -> Id
+transferDFun id id_details =
+  case id_details of
+    DFunId {} -> id `setIdDetails` id_details
+    _ -> id
+
 {-
                 Old (but interesting) stuff about unboxed bindings
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -3517,4 +3529,20 @@ Answer: When they at the top-level (where it is necessary) or when
 inlining would duplicate work (or possibly code depending on
 options). However, the _Lifting will still be eliminated if the
 strictness analyser deems the lifted binding strict.
+
+Note [Transfer DFunId-ness during specialisation]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Whether a binding is a DFunId or not has consequences for the `-fdicts-strict`
+flag, essentially if we are doing demand analysis for a DFunId then `-fdicts-strict` does
+not apply because the constraint solver can create recursive groups of dictionaries.
+
+In #22549 this was fixed for the "normal" case, see Note [Do not strictify the argument dictionaries of a dfun]. However the loop still existed if the DFunId was being specialised.
+
+The problem was that the specialiser would specialise a DFunId and turn it into a
+VanillaId and so the demand analyser didn't know to apply special treatment to the binding
+anymore and the whole recursive group was optimised to bottom.
+
+The solution is to transfer over the DFunId-ness of the binding in the specialiser so
+that the demand analysers knows not to apply the `-fstrict-dicts`
 -}



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/7ecb2983d05c7ff8f45c86fa273875d3cf376f2e

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/7ecb2983d05c7ff8f45c86fa273875d3cf376f2e
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20230414/2e7ccf90/attachment-0001.html>