[Git][ghc/ghc][wip/T24623] Comments only

Simon Peyton Jones (@simonpj) gitlab at gitlab.haskell.org
Mon Jun 17 11:09:14 UTC 2024



Simon Peyton Jones pushed to branch wip/T24623 at Glasgow Haskell Compiler / GHC


Commits:
3f0f3915 by Simon Peyton Jones at 2024-06-17T12:08:49+01:00
Comments only

- - - - -


2 changed files:

- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Types/Demand.hs


Changes:

=====================================
compiler/GHC/Core/Opt/DmdAnal.hs
=====================================
@@ -1106,6 +1106,7 @@ dmdAnalRhsSig top_lvl rec_flag env let_sd id rhs
 
     dmd_sig_arity = ww_arity + calledOnceArity body_sd
     sig = mkDmdSigForArity dmd_sig_arity (DmdType sig_env final_rhs_dmds)
+          -- See Note [mkDmdSigForArity]
 
     opts       = ae_opts env
     final_id   = setIdDmdAndBoxSig opts id sig
@@ -1287,7 +1288,7 @@ BUT we do /not/ want to worker/wrapper `j` with two arguments.  Suppose we have
 
 where j2's join-arity is 1, so calls to `j` will all have /one/ argument.
 Suppose the entire expression is in a called context (like `j` above) and `j2`
-gets the demand signature <P(L)><P(L)>, that is, strict in both arguments.
+gets the demand signature <1!P(L)><1!P(L)>, that is, strict in both arguments.
 
 we worker/wrapper'd `j2` with two args we'd get
      join $wj2 x# y# = let x = I# x#; y = I# y# in rhs
@@ -1377,6 +1378,27 @@ signatures for different arities (i.e., polyvariance) would be entirely
 possible, if it weren't for the additional runtime and implementation
 complexity.
 
+Note [mkDmdSigForArity]
+~~~~~~~~~~~~~~~~~~~~~~~
+Consider
+   f x = case y of { I# y' -> \z -> blah }
+We will analyse the body with demand C(1L), reflecting the single visible
+argument x.  But dmdAnal will return a DmdType looking like
+    DmdType fvs [x-dmd, z-dmd]
+because it has seen two lambdas, \x and \z. Since the length of the argument
+demands in a DmdSig gives the "threshold" for applying the signature
+(see Note [DmdSig: demand signatures, and demand-sig arity] in GHC.Types.Demand)
+we must trim that DmdType to just
+    DmdSig (DmdTypte fvs [x-dmd])
+when making that DmdType into the DmdSig for f.  This trimming is the job of
+`mkDmdSigForArity`.
+
+Alternative.  An alternative would be be to ensure that if
+    (dmd_ty, e') = dmdAnal env subdmd e
+then the length dmds in dmd_ty is always less than (or maybe equal to?) the
+call-depth of subdmd.  To do that we'd need to adjust the Lam case of dmdAnal.
+Probably not hard, but a job for another day; see discussion on !12873.
+
 Note [idArity varies independently of dmdTypeDepth]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 In general, an Id `f` has two independently varying attributes:


=====================================
compiler/GHC/Types/Demand.hs
=====================================
@@ -2136,11 +2136,11 @@ was evaluated. Here's an example:
       else \z -> z * ...
 
 The abstract transformer (let's call it F_e) of the if expression (let's
-call it e) would transform an incoming (undersaturated!) head demand 1A into
-a demand type like {x-><1L>,y-><L>}<L>. In pictures:
+call it e) would transform an incoming (undersaturated!) head sub-demand A
+into a demand type like {x-><1L>,y-><L>}<L>. In pictures:
 
-     Demand ---F_e---> DmdType
-     <1A>              {x-><1L>,y-><L>}<L>
+     SubDemand ---F_e---> DmdType
+     <A>                  {x-><1L>,y-><L>}<L>
 
 Let's assume that the demand transformers we compute for an expression are
 correct wrt. to some concrete semantics for Core. How do demand signatures fit
@@ -2189,10 +2189,10 @@ Here is a table with demand types resulting from different incoming demands we
 put that expression under. Note the monotonicity; a stronger incoming demand
 yields a more precise demand type:
 
-    incoming demand       |  demand type
+    incoming sub-demand   |  demand type
     --------------------------------
-    1A                    |  <L><L>{}
-    C(1,C(1,L))           |  <1P(L)><L>{}
+    P(A)                  |  <L><L>{}
+    C(1,C(1,P(L)))        |  <1P(L)><L>{}
     C(1,C(1,1P(1P(L),A))) |  <1P(A)><A>{}
 
 Note that in the first example, the depth of the demand type was *higher* than



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/3f0f3915bf90938a9015805538ceb8cabebc62a2

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/3f0f3915bf90938a9015805538ceb8cabebc62a2
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/20240617/319036fe/attachment-0001.html>


More information about the ghc-commits mailing list