#14816: Missed Called Arity opportunity?
-------------------------------------+-------------------------------------
Reporter: dfeuer | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone: 8.6.1
Component: Compiler | Version: 8.2.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime | Unknown/Multiple
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by sgraf):
OK, that didn't work, but for reasons I didn't expect. If we apply that
change, suddenly some bindings get *worse* *strictness* annotations,
although it should only make for *less conservative* (possibly unsound)
*usage* annotations, as `reuseEnv` will only affect usage information.
It turns out that this is due to the interaction between the lazy fv hack
and the fix-pointing algorithm. An example is adapted from T876:
{{{
foo :: Int -> Int
foo n = sum [ length [i..n] | i <- [1..n] ]
main = print (foo 100)
}}}
The variant that does get rid of the call to `reuseEnv` altogether will
produce something like this code:
{{{
foo
= \ (n_aYV [Dmd=] :: Int) ->
joinrec {
go_a2c3 [Occ=LoopBreaker] :: [Int] -> Int -> Int
[LclId[JoinId(2)],
Arity=2,
Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True,
WorkFree=True, Expandable=True, Guidance=IF_ARGS [30 20]
137 0}]
go_a2c3 (ds_a2c4 [Dmd=] :: [Int])
(eta_B1 [Dmd=] :: Int)
= case ds_a2c4 of {
[] -> eta_B1;
: y_a2c9 [Dmd=] ys_a2ca ->
jump go_a2c3
ys_a2ca
(case eta_B1 of { GHC.Types.I# x_a3ii [Dmd=] ->
case y_a2c9 of { GHC.Types.I# x_a3jq [Dmd=] ->
case n_aYV of { GHC.Types.I# y_a3jz [Dmd=] ->
case GHC.List.$wlenAcc @ Int (GHC.Enum.eftInt x_a3jq
y_a3jz) 0#
of ww2_a4JP [Dmd=]
{ __DEFAULT ->
GHC.Types.I# (GHC.Prim.+# x_a3ii ww2_a4JP)
}
}
}
})
}; } in
jump go_a2c3
(case n_aYV of { GHC.Types.I# y_a3jz [Dmd=] ->
GHC.Enum.eftInt 1# y_a3jz
})
lvl_s4Jd
}}}
Note that `go` is clearly strict in `n` (that's what HEAD finds out), but
this variant is too conservative. Some printfs revealed that's due to
abortion of fix-pointing. This is a log for the `lazy_fv`s and the
`sig_fv` envs:
{{{
dmdAnalRhsLetDown go_a2c3 [] []
dmdAnalRhsLetDown go_a2c3 [] [aYV :-> ]
dmdAnalRhsLetDown go_a2c3 [aYV :-> ] []
dmdAnalRhsLetDown go_a2c3 [] [aYV :-> ]
dmdAnalRhsLetDown go_a2c3 [aYV :-> ] []
dmdAnalRhsLetDown go_a2c3 [] [aYV :-> ]
dmdAnalRhsLetDown go_a2c3 [aYV :-> ] []
dmdAnalRhsLetDown go_a2c3 [] [aYV :-> ]
dmdAnalRhsLetDown go_a2c3 [aYV :-> ] []
dmdAnalRhsLetDown go_a2c3 [] [aYV :-> ]
dmdAnalRhsLetDown go_a2c3 [] [aYV :-> ]
dmdAnalRhsLetDown foo [] []
}}}
It flip flops between putting `n`s demand into the `sig_fv` and the
`lazy_fv`. That's decided by `isWeakDmd`, which amounts to checking if the
demand is equivalent to `` and will thus no longer change during fix-
pointing. After the initial iteration, we find that `n` is called once and
gets tagged onto the strictness signature. The second iteration sees that
`n` is called an additional time, demand ``. This means it no
longer has an interesting demand and goes into `lazy_fv`. But here's the
culprit: The fix-pointer only compares the strictness signature for
changes! It will start a third iteration, completely forget about any
`lazy_fv` and flop back to the state of the first iteration.
There's two ways out:
1. Also check `lazy_fvs` for changes. This is the thing we wanted to avoid
in the first place. Also this is LetUp in disguise, which purposefully
isn't equipped to deal with recursive bindings.
2. Don't check `lazy_fvs`. These are outer bindings only, so they don't
actually need to play a role in fix-pointing. Also everything in
`lazy_fvs` is already top-ish, so it suffices to check if a variable in a
prior signature is now part of `lazy_fvs` and exclude them from the check.
I'll try 2. tomorrow.
--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14816#comment:12
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
