[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