[project @ 1999-07-14 14:40:20 by simonpj]

Main things:

* Add splitProductType_maybe to DataCon.lhs, with type
  splitProductType_maybe
	:: Type 			-- A product type, perhaps
	-> Maybe (TyCon, 		-- The type constructor
		  [Type],		-- Type args of the tycon
		  DataCon,		-- The data constructor
		  [Type])		-- Its *representation* arg types

  Then use it in many places (e.g. worker-wrapper places) instead
  of a pile of junk

* Clean up various uses of dataConArgTys, which were plain wrong because
  they weren't passed the existential type arguments.  Most of these calls
  are eliminated by using splitProductType_maybe above.  I hope I correctly
  squashed the others. This fixes a bug that Meurig's programs showed up.

    module FailGHC (killSustainer) where
    import Weak
    import IOExts

    data Sustainer = forall a . Sustainer (IORef (Maybe a)) (IO ())

    killSustainer :: Sustainer -> IO ()
    killSustainer (Sustainer _ act) = act

  The above program used to kill the compiler.

* A fairly concerted attack on the Dreaded Space Leak.
	- Add Type.seqType, CoreSyn.seqExpr, CoreSyn.seqRules

	- Add some seq'ing when building Ids and IdInfos
		These reduce the space usage a lot

	- Add CoreSyn.coreBindsSize, which is pretty strict in the program,
		and call it when we have -dshow-passes.

	- Do not put the inlining in an Id that is being plugged into
		the result-expression of the simplifier.  This cures
		a the 'wedge' in the space profile for reasons I don't understand fully

  Together, these things reduce the max space usage when compiling PrelNum from
  17M to about 7Mbytes.

  I think there are now *too many* seqs, and they waste work, but I don't have
  time to find which ones.

  Furthermore, we aren't done. For some reason, some of the stuff allocated by
  the simplifier makes it through all during code generation and I don't see why.
  There's a should-be-unnecessary call to coreBindsSize in Main.main which
  zaps some, but not all of this space.

  -dshow-passes reduces space usage a bit, but I don't think it should really.

  All the measurements were made on a compiler compiled with profiling by
  GHC 3.03.    I hope they carry over to other builds!

* One trivial thing: changed all variables 'label' to 'lbl', becuase the
  former is a keyword with -fglagow-exts in GHC 3.03 (which I was compiling with).
  Something similar in StringBuffer.

1 files changed, 3 insertions, 3 deletions

diff --git a/ghc/compiler/codeGen/CgClosure.lhs b/ghc/compiler/codeGen/CgClosure.lhs
index e04a4c2943..26c7e51e44 100644
--- a/ghc/compiler/codeGen/CgClosure.lhs
+++ b/ghc/compiler/codeGen/CgClosure.lhs
@@ -1,7 +1,7 @@
 %
 % (c) The GRASP/AQUA Project, Glasgow University, 1992-1998
 %
-% $Id: CgClosure.lhs,v 1.33 1999/06/24 13:04:17 simonmar Exp $
+% $Id: CgClosure.lhs,v 1.34 1999/07/14 14:40:28 simonpj Exp $
 %
 \section[CgClosure]{Code generation for closures}
 
@@ -538,7 +538,7 @@ argSatisfactionCheck closure_info
 
 \begin{code}
 thunkWrapper:: ClosureInfo -> CLabel -> Code -> Code
-thunkWrapper closure_info label thunk_code
+thunkWrapper closure_info lbl thunk_code
   = 	-- Stack and heap overflow checks
     nodeMustPointToIt (closureLFInfo closure_info) `thenFC` \ node_points ->
 
@@ -554,7 +554,7 @@ thunkWrapper closure_info label thunk_code
       else absC AbsCNop)                       `thenC`
 
         -- stack and/or heap checks
-    thunkChecks label node_points (
+    thunkChecks lbl node_points (
 
 	-- Overwrite with black hole if necessary
     blackHoleIt closure_info node_points	`thenC`