diff options
author | Simon Peyton Jones <simonpj@microsoft.com> | 2017-08-25 09:22:03 +0100 |
---|---|---|
committer | Simon Peyton Jones <simonpj@microsoft.com> | 2017-08-25 12:57:11 +0100 |
commit | 33452dfc6cf891b59d63fa9fe138b18cbce4df81 (patch) | |
tree | e6cc85f4e02d0f792d3e44a28958b7261cf3fb44 /testsuite/tests/simplCore/should_compile/rule2.stderr | |
parent | 407c11b880325f4f327982d4f6b9f9cba4564016 (diff) | |
download | haskell-33452dfc6cf891b59d63fa9fe138b18cbce4df81.tar.gz |
Refactor the Mighty Simplifier
Triggered by #12150, and the knock-on effects of join points, I did a
major refactoring of the Simplifier. This is a big patch that change
a lot of Simplify.hs: I did a lot of other re-organisation.
The main event
~~~~~~~~~~~~~~
Since the dawn of time we have had
simplExpr :: SimplEnv -> InExpr -> SimplCont
-> SimplM (SimplEnv, OutExpr)
What's that SimplEnv in the result? When simplifying an expression the
simplifier add floated let-bindings to the SimplEnv, extending the
in-scope set appropriately, and hence needs to resturn the SimplEnv at
the end. The mode, flags, substitution in the returned SimplEnv were
all irrelevant: it was just the floating bindings.
It's strange to accumulate part of the /result/ in the /environment/
argument! And indeed its leads to all manner of mysterious calls to
zapFloats and transferring of floats from one SimplEnv to another.
It got worse with join points, so I finally bit the bullet and refactored.
Now we have
simplExpr :: SimplEnv -> InExpr -> SimplCont
-> SimplM (SimplFloats, OutExpr)
-- See Note [The big picture]
and the SimplEnv no longer has floats in it. The code is no shorter,
but it /is/ easier to understand.
Main changes
* Remove seLetFloats field from SimplEnv
* Define new data type SimplFloats, and functions over it
* Change the types of simplExpr, simplBind, and their many variants,
to follow the above plan
Bottoming bindings
~~~~~~~~~~~~~~~~~~
I made one other significant change in SimplUtils (not just refactoring),
related to Trac #12150 comment:16. Given
x = <rhs>
where <rhs> turns out to be a bottoming expression, propagate that
information to x's IdInfo immediately. That's always good, because
it makes x be inlined less (we don't inline bottoming things), and
it allows (case x of ...) to drop the dead alterantives immediately.
Moreover, we are doing the analysis anyway, in tryEtaExpandRhs, which
calls CoreArity.findRhsArity, which already does simple bottom analysis.
So we are generating the information; all we need do is to atach the
bottoming info to the IdInfo.
See Note [Bottoming bindings]
Smaller refactoring
~~~~~~~~~~~~~~~~~~~
* Rename SimplifierMode to SimplMode
* Put DynFlags as a new field in SimplMode, to make fewer
monadic calls to getDynFlags.
* Move the code in addPolyBind into abstractFloats
* Move the "don't eta-expand join points" into tryEtaExpandRhs
Diffstat (limited to 'testsuite/tests/simplCore/should_compile/rule2.stderr')
-rw-r--r-- | testsuite/tests/simplCore/should_compile/rule2.stderr | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/testsuite/tests/simplCore/should_compile/rule2.stderr b/testsuite/tests/simplCore/should_compile/rule2.stderr index 7444cc90a4..35bcec7835 100644 --- a/testsuite/tests/simplCore/should_compile/rule2.stderr +++ b/testsuite/tests/simplCore/should_compile/rule2.stderr @@ -10,12 +10,12 @@ ==================== Grand total simplifier statistics ==================== -Total ticks: 13 +Total ticks: 11 1 PreInlineUnconditionally 1 f 1 UnfoldingDone 1 Roman.bar 1 RuleFired 1 foo/bar -3 LetFloatFromLet 3 +1 LetFloatFromLet 1 1 EtaReduction 1 ds 6 BetaReduction 1 f |