[Git][ghc/ghc][wip/T17932] Demand analysis: simplify the demand for a RHS
Sebastian Graf
gitlab at gitlab.haskell.org
Fri Mar 20 12:39:04 UTC 2020
Sebastian Graf pushed to branch wip/T17932 at Glasgow Haskell Compiler / GHC
Commits:
aa89fe2d by Simon Peyton Jones at 2020-03-20T12:38:58Z
Demand analysis: simplify the demand for a RHS
Ticket #17932 showed that we were using a stupid demand for the RHS
of a let-binding, when the result is a product. This was the result
of a "fix" in 2013, which (happily) turns out to no longer be
necessary.
So I just deleted the code, which simplifies the demand analyser,
and fixes #17932.
I tried nofib, and got 0.0% perf changes.
All this came up when messing about with !2873 (ticket #17917),
but is idependent of it.
- - - - -
4 changed files:
- compiler/GHC/Core/Op/DmdAnal.hs
- + testsuite/tests/stranal/sigs/T17932.hs
- + testsuite/tests/stranal/sigs/T17932.stderr
- testsuite/tests/stranal/sigs/all.T
Changes:
=====================================
compiler/GHC/Core/Op/DmdAnal.hs
=====================================
@@ -617,16 +617,11 @@ dmdAnalRhsLetDown rec_flag env let_dmd id rhs
is_thunk = not (exprIsHNF rhs) && not (isJoinId id)
-- | @mkRhsDmd env rhs_arity rhs@ creates a 'CleanDemand' for
--- unleashing on the given function's @rhs@, by creating a call demand of
--- @rhs_arity@ with a body demand appropriate for possible product types.
--- See Note [Product demands for function body].
--- For example, a call of the form @mkRhsDmd _ 2 (\x y -> (x, y))@ returns a
--- clean usage demand of @C1(C1(U(U,U)))@.
+-- unleashing on the given function's @rhs@, by creating
+-- a call demand of @rhs_arity@
+-- See Historical Note [Product demands for function body]
mkRhsDmd :: AnalEnv -> Arity -> CoreExpr -> CleanDemand
-mkRhsDmd env rhs_arity rhs =
- case peelTsFuns rhs_arity (findTypeShape (ae_fam_envs env) (exprType rhs)) of
- Just (TsProd tss) -> mkCallDmds rhs_arity (cleanEvalProdDmd (length tss))
- _ -> mkCallDmds rhs_arity cleanEvalDmd
+mkRhsDmd _env rhs_arity _rhs = mkCallDmds rhs_arity cleanEvalDmd
-- | If given the let-bound 'Id', 'useLetUp' determines whether we should
-- process the binding up (body before rhs) or down (rhs before body).
@@ -857,9 +852,9 @@ forward plusInt's demand signature, and all is well (see Note [Newtype arity] in
GHC.Core.Arity)! A small example is the test case NewtypeArity.
-Note [Product demands for function body]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-This example comes from shootout/binary_trees:
+Historical Note [Product demands for function body]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+In 2013 I spotted this example, in shootout/binary_trees:
Main.check' = \ b z ds. case z of z' { I# ip ->
case ds_d13s of
@@ -878,8 +873,12 @@ Here we *really* want to unbox z, even though it appears to be used boxed in
the Nil case. Partly the Nil case is not a hot path. But more specifically,
the whole function gets the CPR property if we do.
-So for the demand on the body of a RHS we use a product demand if it's
-a product type.
+That motivated using a demand of C(C(C(S(L,L)))) for the RHS, where
+(solely because the result was a product) we used a product demand
+(albeit with lazy components) for the body. But that gives very silly
+behaviour -- see #17932. Happily it turns out now to be entirely
+unnecessary: we get good results with C(C(C(S))). So I simply
+deleted the special case.
************************************************************************
* *
=====================================
testsuite/tests/stranal/sigs/T17932.hs
=====================================
@@ -0,0 +1,11 @@
+-- See commentary in #17932
+
+module T17932 where
+
+flags (Options f x)
+ = reverse (reverse (reverse (reverse (reverse (reverse (reverse (reverse x)))))))
+ `seq` f
+
+data X = X String Bool Bool Bool Bool
+
+data Options = Options !X [Int]
=====================================
testsuite/tests/stranal/sigs/T17932.stderr
=====================================
@@ -0,0 +1,30 @@
+
+==================== Strictness signatures ====================
+T17932.$tc'Options:
+T17932.$tc'X:
+T17932.$tcOptions:
+T17932.$tcX:
+T17932.$trModule:
+T17932.flags: <S(SS),1*U(1*U,1*U)>
+
+
+
+==================== Cpr signatures ====================
+T17932.$tc'Options: m1
+T17932.$tc'X: m1
+T17932.$tcOptions: m1
+T17932.$tcX: m1
+T17932.$trModule: m1
+T17932.flags: m1
+
+
+
+==================== Strictness signatures ====================
+T17932.$tc'Options:
+T17932.$tc'X:
+T17932.$tcOptions:
+T17932.$tcX:
+T17932.$trModule:
+T17932.flags: <S(SS),1*U(1*U,1*U)>
+
+
=====================================
testsuite/tests/stranal/sigs/all.T
=====================================
@@ -19,3 +19,4 @@ test('T12370', normal, compile, [''])
test('CaseBinderCPR', normal, compile, [''])
test('NewtypeArity', normal, compile, [''])
test('T5075', normal, compile, [''])
+test('T17932', normal, compile, [''])
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/commit/aa89fe2dec16e68b77dc13574a503a00c589fe5c
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/commit/aa89fe2dec16e68b77dc13574a503a00c589fe5c
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/20200320/eb0fc260/attachment-0001.html>
More information about the ghc-commits
mailing list