Stamp out space leaks from demand analysis

This reduces peak memory usage by ~30% on my test case (DynFlags),
and (probably as a result of reduced GC work) decreases compilation
time by a few percent as well.

Also fix a bug in seqStrDmd so that demeand info is fully evaluated.

Reviewers: simonpj, austin, bgamari

Reviewed By: bgamari

Subscribers: dfeuer, thomie

Differential Revision: https://phabricator.haskell.org/D3400

1 files changed, 21 insertions, 1 deletions

diff --git a/compiler/stranal/DmdAnal.hs b/compiler/stranal/DmdAnal.hs
index 25a4f8b912..2fc33a48b8 100644
--- a/compiler/stranal/DmdAnal.hs
+++ b/compiler/stranal/DmdAnal.hs
@@ -17,6 +17,7 @@ import DynFlags
 import WwLib            ( findTypeShape, deepSplitProductType_maybe )
 import Demand   -- All of it
 import CoreSyn
+import CoreSeq          ( seqBinds )
 import Outputable
 import VarEnv
 import BasicTypes
@@ -52,7 +53,8 @@ dmdAnalProgram dflags fam_envs binds
         dumpIfSet_dyn dflags Opt_D_dump_str_signatures
                       "Strictness signatures" $
             dumpStrSig binds_plus_dmds ;
-        return binds_plus_dmds
+        -- See Note [Stamp out space leaks in demand analysis]
+        seqBinds binds_plus_dmds `seq` return binds_plus_dmds
     }
   where
     do_prog :: CoreProgram -> CoreProgram
@@ -79,6 +81,24 @@ dmdAnalTopBind sigs (Rec pairs)
                 -- We get two iterations automatically
                 -- c.f. the NonRec case above
 
+{- Note [Stamp out space leaks in demand analysis]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The demand analysis pass outputs a new copy of the Core program in
+which binders have been annotated with demand and strictness
+information. It's tiresome to ensure that this information is fully
+evaluated everywhere that we produce it, so we just run a single
+seqBinds over the output before returning it, to ensure that there are
+no references holding on to the input Core program.
+
+This is particularly important when we are doing late demand analysis,
+since we don't do a seqBinds at any point thereafter. Hence code
+generation would hold on to an extra copy of the Core program, via
+unforced thunks in demand or strictness information; and it is the
+most memory-intensive part of the compilation process, so this added
+seqBinds makes a big difference in peak memory usage.
+-}
+
+
 {-
 ************************************************************************
 *                                                                      *