Commit 2acfaae9 authored by Simon Peyton Jones's avatar Simon Peyton Jones

Comments only

parent 928d7473
......@@ -1335,28 +1335,30 @@ field of the AnalEnv.
Note [Final Demand Analyser run]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Some of the information that the demand analyser determines is not always
preserved by the simplifier, for example, the simplifier will happily rewrite
preserved by the simplifier. For example, the simplifier will happily rewrite
\y [Demand=1*U] let x = y in x + x
to
\y [Demand=1*U] y + y
which is quite a lie.
The once-used information is (currently) only used by the code generator, though. So we
* do not bother keeping this information up-to-date in the simplifier, or
removing it after the demand analyser is done (keeping in mind not to
critically rely on this information in, say, the simplifier).
It should still be fine to use this as in heuristics, e.g. when deciding to
inline things, as the data will usually be correct.
* Just before TidyCore, we add a pass of the demand analyse, without
subsequent worker/wrapper and simplifier, right before TidyCore.
This way, correct information finds its way into the module interface
The once-used information is (currently) only used by the code
generator, though. So:
* We zap the used-once info in the woker-wrapper;
see Note [Zapping Used Once info in WorkWrap] in WorkWrap. If it's
not reliable, it's better not to have it at all.
* Just before TidyCore, we add a pass of the demand analyser,
but WITHOUT subsequent worker/wrapper and simplifier,
right before TidyCore. See SimplCore.getCoreToDo.
This way, correct information finds its way into the module interface
(strictness signatures!) and the code generator (single-entry thunks!)
Note that the single-call information (C1(..)) can be relied upon, as the
simplifier tends to be very careful about not duplicating actual function
calls.
Note that, in contrast, the single-call information (C1(..)) /can/ be
relied upon, as the simplifier tends to be very careful about not
duplicating actual function calls.
Also see #11731.
-}
......@@ -321,10 +321,7 @@ tryWW dflags fam_envs is_rec fn_id rhs
{-
Note [Zapping DmdEnv after Demand Analyzer]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the worker-wrapper pass we zap the DmdEnv.
Why?
In the worker-wrapper pass we zap the DmdEnv. Why?
(a) it is never used again
(b) it wastes space
(c) it becomes incorrect as things are cloned, because
......@@ -336,14 +333,14 @@ Why here?
* We want them to be still there at the end of DmdAnal, so that
-ddump-str-anal contains them.
* We don’t want a second pass just for that.
* WorkWrap looks at all bindings anyways.
* WorkWrap looks at all bindings anyway.
We also need to do it in TidyCore to clean up after the final,
worker/wrapper-less run of the demand analyser.
We also need to do it in TidyCore.tidyLetBndr to clean up after the
final, worker/wrapper-less run of the demand analyser (see
Note [Final Demand Analyser run] in DmdAnal).
Note [Zapping Used Once info in WorkWrap]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the worker-wrapper pass we zap the used once info in demands and in
strictness signatures.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment