[commit: ghc] master: Comments only (c407b5a)

[git at git.haskell.org]

Repository : ssh://git@git.haskell.org/ghc

On branch  : master
Link       : http://ghc.haskell.org/trac/ghc/changeset/c407b5a6e206764a04d041dcb1894ce737d23cb0/ghc

>---------------------------------------------------------------

commit c407b5a6e206764a04d041dcb1894ce737d23cb0
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date:   Tue Dec 23 15:41:59 2014 +0000

    Comments only


>---------------------------------------------------------------

c407b5a6e206764a04d041dcb1894ce737d23cb0
 compiler/typecheck/TcFlatten.hs | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/compiler/typecheck/TcFlatten.hs b/compiler/typecheck/TcFlatten.hs
index 2b11f99..3e13a00 100644
--- a/compiler/typecheck/TcFlatten.hs
+++ b/compiler/typecheck/TcFlatten.hs
@@ -978,10 +978,7 @@ Examples that are helped are tests T9872, and T5321Fun.
 Performance testing indicates that it's best to try this *twice*, once
 before flattening arguments and once after flattening arguments.
 Adding the extra reduction attempt before flattening arguments cut
-the allocation amounts for the T9872{a,b,c} tests by half. Testing
-also indicated that the early reduction should not use the flat-cache,
-but that the later reduction should. It's possible that with more
-examples, we might learn that these knobs should be set differently.
+the allocation amounts for the T9872{a,b,c} tests by half.
 
 An example of where the early reduction appears helpful:
 
@@ -995,6 +992,14 @@ Flattening the argument never gets us anywhere, but trying to flatten
 it at every step is quadratic in the length of the list. Reducing more
 eagerly makes simplifying the right-hand type linear in its length.
 
+Testing also indicated that the early reduction should *not* use the
+flat-cache, but that the later reduction *should*. (Although the
+effect was not large.)  Hence the Bool argument to try_to_reduce.  To
+me (SLPJ) this seems odd; I get that eager reduction usually succeeds;
+and if don't use the cache for eager reduction, we will miss most of
+the opportunities for using it at all.  More exploration would be good
+here.
+
 At the end, once we've got a flat rhs, we extend the flatten-cache to record
 the result. Doing so can save lots of work when the same redex shows up more
 than once. Note that we record the link from the redex all the way to its