• Simon Peyton Jones's avatar
    [project @ 1999-07-14 14:40:20 by simonpj] · 4e7d56fd
    Simon Peyton Jones authored
    Main things:
    * Add splitProductType_maybe to DataCon.lhs, with type
    	:: 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.